Re: [Haskell-cafe] Question about concurrency, threads and GC

Fri, Mar 02, 2012 at 07:34:41PM -0500, Joey Adams wrote

On Fri, Mar 2, 2012 at 3:04 PM, Alexander V Vershilov wrote:

...

Hello, Paul.

It seems you should not use 3 threads, but run in a data-driven behaviour with one thread per client.

I don't think this will work for Paul's situation. He needs to be able to send notifications to clients. This means sending to the client even when the client has nothing to say at the moment.

I've been grappling with the same problem. See:

http://www.haskell.org/pipermail/haskell-cafe/2012-January/098495.html

The discussion was recently summed up in Parallel Haskell Digest 8 (scroll down to "How to make asynchronous I/O composable and safe?"):

http://www.well-typed.com/blog/64

To try to address this problem, I wrote a module called stm-channelize:

http://hackage.haskell.org/package/stm-channelize

However, I did not end up using it. I would point you to the source of my channelize function, but I think it's more complicated than it needs to be.

I, for one, would recommend a three-thread approach. That is, for each client, you basically have:

* A thread for receiving

* A thread for sending

* A main thread that waits for the other two threads, and kills them when one of them finishes or dies.

I'll try to put together a simple chat server example, like the one I wrote for stm-channelize.

-Joey

Yes, there is no way to use only one thread for such a case, but conduit aproach seems quite easy and take care about resources. Recently I wrote a question about such a situation [1] and it simplification [1] http://www.haskell.org/pipermail/haskell-cafe/2012-February/099770.html I've used smth like stm-channelize approach to make "virtual socket" when there was many clients on one connection. I can check stm-channelize more precietly and write if my aproach has usefull idea for that case. -- Alexander Vershilov.