[Haskell-cafe] Re: Bringing Erlang to Haskell

[Joel Reymont]

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/