Hello, Paul. It seems you should not use 3 threads, but run in a data-driven behaviour with one thread per client. You can take a look at network-conduit [1] example, there is a very good aproach to tcp-network application. There are some iteratee based examples but they are not so extensible.
[1] http://hackage.haskell.org/package/network-conduit -- Alexander Vershilov Fri, Mar 02, 2012 at 08:19:56PM +0400, Paul Graphov wrote > Hello Cafe! > > I am trying to implement networked application in Haskell. It should accept > many > client connections and support bidirectional conversation, that is not > just loop with > Request -> Response function but also sending notifications to clients etc. > > NB: I came from C++ background and used to explicit asynchonous operations > and pools of OS threads. (Boost.Asio + Boost.Thread) > > There seem to be lots of goodies around (green threads, STM). The > problem is that > I cannot figure out how to design such applications. First of all now > I have to start > some threads for each client. Client state and behaviour may change depending > on > data that comes from it or other clients. So it seems that I have to > start at least three > threads: one that reads data from socket, one that sends queued messages to > the socket and one that represents clients main behaviour loop. The > last one will > supposedly read from some STM sources, one of them being TChan/TMVar filled > by thread that reads socket. Here I get stuck: how to manage that threads? > > I tried to search STM examples at hackage and the most interesting > packages were: > > 1) combinatorrent - quite complex application, but it seem to be > highly Erlang-inspired, > so I am not sure that it is the simplest way of doing thing. > > 2) network-connection package - it is a library that wraps socket and > uses STM internally > but exposes almost the same interface with blocking operations. Thread > management is > quite explicit there. But this package is marked obsolete. > > I wondered if one can rely upon garbage collector to reap dead threads > when using STM? > Or is it too error prone (accidental references to STM object that > prevent it from being > collected) and unpredictable? > > I have read this post: > http://blog.ezyang.com/2011/07/blockedindefinitelyonmvar/ > > It shows that relying upon handling BlockedIndefinitelyOn* exceptions > is a bad idea but > is it OK just to rely upon that blocked forever thread will die and > not to kill it explicitly? > > And also if it is really reliable, what are exact rules when some > object goes out of scope > and becomes collectable? For example in blog post mentioned above in > "main1" example > "lock" variable is accessible until the end of do-block, i.e. if I add > "takeMVar lock" line to > its end, it will compile. But it is not used actually. Is it > guaranteed that explicit performGC > will reap it? > > Possibly the best answer would be just pointing me to some recent > examples of concurrent > network applications. > > Thanks! > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe
signature.asc
Description: Digital signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe