On Dec 6, 2005, at 1:49 PM, Bulat Ziganshin wrote:
JR> #1 reading messages from a socket and posting to #3, JR> #2 reading messages sent by #3 and writing to the socket, JR> #3 reading messages sent by #1, processing them and posting to #2.
what you get by dividing this into 3 threads? i think that this have meaning ONLY if you then join all socket reading threads together and use one select to wait on them all
I get an abstraction of a thread with two STM-based mailboxes. My workhorse threads don't need to care what is done with the messages that they generate and where the ones that they are consuming come from.
JR> | Custom Dynamic -- can't pattern-match on this? JR> deriving Show
using "Dynamic" have meaning only if you don't know at compile time what messsages can be sent. is that really the case?
That is correct. I deliver a "scripting library" and users can create messages of their own.
imho, you are think in Erlang style, which is ultimately dynamic and run-time oriented.
I think in the style most suitable to my task at hand. I have a variable number of poker clients that talk to the server. These all run concurrently so I'm starting threads for them. They can send/receive messages, so I added mailboxes to the threads, etc. Is there anything wrong with this approach? Thanks, Joel -- http://wagerlabs.com/