[zeromq-dev] FOSDEM talk on 0MQ - video & slides

Vladimir Lebedev valebedev at gmail.com
Tue Feb 8 09:21:35 CET 2011


Let's look at the formal definition of Actor model (G. Agha, 1985):

Actors are computational agents which map each incoming communication to 
a 3-tuple consisting of:

1. a finite set of communications sent to other actors;
2. a new behavior (which will govern the response to the next commu-
nication processed); and,
3. a finite set of new actors created.

If translated to normal language, the above becomes the following:

Actors are lightweight processes which may send messages to other 
processes, keep their state locally and may launch more processes. So, I 
didn't see the contradiction with 0MQ now.

Yes, the Actor model defines special message handling:

a. message send is strictly asynchronous (fire-and-forget)
b. message receive is strictly blocking (no events - no computations - 
no state change)
c. each actor has message mailbox for incoming messages (buffer or queue).

Again, I see no contradiction with 0MQ. Sure, it would be impractical to 
implement actors using REQ/REP, because PUSH/PULL semantics is more 
suitable for this. Though when defining the API for hypothetical actor 
library you may completely hide these details (like 0MQ socket 
types/messaging patterns) from the user. Then this API will export only 
one type of communication: fire-and-forget style.

Best regards,


On 07.02.2011 19:28, Martin Sustrik wrote:
> On 02/07/2011 04:22 PM, gonzalo diethelm wrote:
>> It got me thinking: I don't think we have a real Actor Model implemented on top of 0MQ, something that actually has actors, messages, addresses, etc.
> I would say that 0MQ is an layer on top of actor model. Actor model
> allows you to send a message to anyone at any time. 0MQ restricts your
> freedom in what you can send to whom and when. You have to comply with
> semantics of the messaging pattern you are using. This restriction is
> meant to impose scalable designs on you and prevent you from shooting
> yourself into the foot but using ad hoc unscalable patterns.
> That, AFAICS, prevents you from implementing generic actor library on
> top of 0MQ.
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list