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/
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
