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/

On 12/12/05, Joel Reymont wrote:

Folks,

I love the Erlang multi-processing experience and think that a lot of the mistakes that I made could be avoided. What I want to have is

1) Processes, aka threads with single-slot in/out mailboxes 2) A facility to keep a list of such processes and send events to them using their process id 3) A socket reader/writer abstraction that communicates with the outside world using using its mailboxes

Probably some other things but I would start with the above. I also want to use STM for this.

One particular thing that bugs me is that I cannot really use TChan for thread mailboxes. I don't think I experienced this problem with Erlang but using a TChan with a logger thread quickly overwhelms the logger and fills the TChan and a lot (hundreds? thousands) of other threads are logging to it. Someone said it's because the scheduler would give ther other threads proportionally more attention.

You could use a bounded TChan. Chans are good because the smooth out "noise".. Ie a sudden surge of messages can be handled without stalling the senders, but sustained heavy traffic will cause a stall (preventing the TChan from growing too big). Here's an untested, off-the-top-of-my-head, implementation.. I may have gotten some names wrong but it should be quite straightforward to write a "real" implementation.. -- may want a newtype here? type BoundedTChan a = (TVar Int, Int, TChan a) -- (current size, max, chan) newBoundedTChan n = do sz <- newTVar 0 ch <- newTChan return (sz,n,ch) writeBoundedTChan (sz,mx,ch) x = do s <- readTVar sz when (s >= mx) retry writeTVar sz (s+1) writeChan ch x readBoundedTChan (sz,mx,ch) = do modifyTVar sz (-1) readTChan ch (s+1) /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862