> From: Heka Treep <zena.treep at gmail.com>
> Subject: Re: Is it true that an exception is always terminates the
> thread?
> To: "Edward Z. Yang" <ezyang at mit.edu>
> Cc: glasgow-haskell-users <glasgow-haskell-users at haskell.org>
> Message-ID:
> <CAMChDeP5mv7pu8+MbR_NZzm3vCF-3AqxY7PiOHBA8R91yWCyrQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>> 2012/1/23, Edward Z. Yang <ezyang at mit.edu>:
>> Excerpts from Heka Treep's message of Mon Jan 23 13:56:47 -0500 2012:
>>> adding the message queue (with Chan, MVar or STM) for each process will
>>> not
>>> help in this kind of imitation.
>>>> Why not? Instead of returning a thread ID, send the write end of a Chan
>> which the thread is waiting on. You can send messages (normal or
>> errors) using it.
>>>> Edward
>>>> Yes, one can write this:
(others have commented on your actor implementation already)
I'm not certain I understand your comment about synchronization; the
STM implementation handles all of that. Unless you mean that you'd
rather not write the "atomically"'s when writing to the TChan. But
you can define:
> ! :: TChan a -> a -> IO ()
> chan ! msg = atomically $ writeTChan chan msg
This allows you to write:
> test = do
> mbox <- spawn actor
> mbox ! "1"
> mbox ! "2"
> mbox ! "3"
which seems to be exactly what you want.
For the record, it's probably possible to do this with async
exceptions, but I would not want to maintain it. For one, async
exceptions are how GHC implements a lot of thread management stuff
(e.g. the ThreadKilled exception). You would need to be careful that
your code doesn't interfere with that. Another concern is the thread
mask state, which needs to be handled carefully. For example, if you
perform an "interruptable operation" while processing the message
(e.g. blocking IO), another message could be received at that point,
which I believe would abort processing of the first message. If you
use "uninterruptableMask", then as I read the docs you can't block *at
all* without making the thread unkillable.
Doing this with async exceptions would be tricky to get right. STM is
the best approach.
John L.