Just to elaborate a bit... On Dec 12, 2005, at 4:00 PM, Joel Reymont wrote:
1) Processes, aka threads with single-slot in/out mailboxes
It's obvious that the thread id and the mailboxes (two TMVar's) would need to be kept together, i.e. a) data Process = ThreadId (TMVar Dynamic) (TMVar Dynamic) or b) data Process a = ThreadId (TMVar a) (TMVar a) but I'm not sure if I should create a process class, for example. I think a class is not really needed since a message "receive" function can just use myThreadId to obtain a key into the map of processes and retrieve the message from its own mailbox. receive could take an action that's parameterized on the event and could pattern-match on it to process the event. This is why I would much rather prefer (b) above. I foresee myself having a single Event type throughout my app with various constructors. Processes can be supervised by rethrowing exceptions back to the parent thread I think.
2) A facility to keep a list of such processes and send events to them using their process id
I'm looking to use a global variable for this but then events would either need to be Dynamic or great care would need to be excercised with unsafeIO (Tomasz? ;-)) I still think this is the way to tackle the issue (note Process a). {-# NOINLINE children #-} children :: MVar [Process a] children = unsafePerformIO $ newMVar [] So long as everything is parameterized throughout, my experience is that the type checker complains if you try to use two types of 'a' throughout the app.
3) A socket reader/writer abstraction that communicates with the outside world using using its mailboxes
What I would like to do here is to use STM to read either from the socket loop mailbox or from the socket itself and then dispatch accordingly. If the message came from the socket then it's posted to the outbox and if a message was retrieved from the inbox then it gets posted to the socket. Some sort of a timeout would be needed for blocking I/O or a combination of hWaitForInput and -threaded. Thanks, Joel P.S. Einar apparently has distributed transactions almost ready. Putting them together with a polished version of the above should make distributed concurrent programming in Haskell far less tricky. -- http://wagerlabs.com/