[Haskell-cafe] Best Actor system?

james james at mansionfamily.plus.com
Fri Mar 28 19:13:06 UTC 2014


(Isn't it nice to be on a list where peopel top-post? ;-))

Actually I already have Haskell-like code at work where I have 
actor-like processing with
(event, state) -> (state', actions) and these are mostly pure. And I 
like the model.

I'm NOT looking for spreading over boxes.  What I'm interested in is 
optimisation of the flow of control:
  - if an actor has a deep queue of input events, I want it to spin 
in-cache efficiently.
  - if an actor makes an RPC-like transaction against a dormant peer, 
then I want the flow of control
   on the bound thread to go from one to the other and back, and not 
result in general scheduling
  - I want the performance of general messaging to be somewhat like that 
of the work-stealing
   pool we see working well in Akka and JActor

I would be surprised if general LWP scheduling will really be up to it, 
in terms of competing,
particularly in the case of RPC interactions or pipelines where we'd 
really want to stay cache-hot
for either the code (for an actor spinning on a deep queue) or the data 
(for a pipeline or RPC).

I'm also interested in terms of how a channel can effectively (and 
efficiently) handle messages where
the channel is carrying a union of message types that can evolve as the 
system is built.

I'm quite happy to do explicit networking between processes in different 
NUMA zones or on
different hosts.

James

(Not made my mind up about Erlang - I really like per-actor GC tho.  
Will try to play with
Nimrod sometime)

On 27/03/2014 22:34, amindfv at gmail.com wrote:
> Unfortunately I can't help with recommending an actor library. I think 
> peoples' responses of "you should never want to do that" are, um, 
> unhelpful.
>
> That said, i've written both haskell and erlang professionally, and 
> never had a need for actors/message passing in haskell. It may be the 
> wrong tool for most haskell jobs.
>
> The main things erlang-style concurrency gets you are
>  - lightweight threads (in haskell by default -- 'forkIO' creates 
> lightweight threads)
>  - limited shared mutable state (haskell's pure)
>  - spreading computation over cores (in haskell you want parallelism 
> not concurrency -- check out the Par monad)
>  - computation over boxes (see distributed-process)
>
> To do "message passing", check out MVars (and later, STM)
>
> Tom



More information about the Haskell-Cafe mailing list