Home » forums » LtU Forum

Actors vs. Reactive Objects

In their paper Reactive Objects the authors compare reactive objects to the actor model (at the end of the Related Work section). They give three advantages reactive objects have over actors:

  1. messages to undefined methods are simply queued
  2. the Actor model lacks synchronous messages
  3. asynchronous message delivery is not order-preserving

These may have been true of the original Actor model but a modern implementation seems to feature improvements to all three points. For example, on point 2, Io features both synchronous & asynchronous message passing, where you either synchronise on the result, send the message asynchronously (prefix any message with @ and be given a future that transforms into the final result when known) or send it & ignore the result (prefix any message with @@). Undefined messages are sent up the inheritance chain, and asynchronous message delivery is handled on a first-in first-out basis.

What alternative do reactive objects offer on point 1? I've not managed to work that out from the paper. Any pointers would be appreciated! I'm basically trying to situate Reactive Objects in comparison to the Actor model, functional-reactive programming, and other means of situating software as a means of responding to it's environment rather than the other way around (particularly in relation to GUI research).

By Oliver Mooney at 2007-04-19 15:01 | LtU Forum | previous forum topic | next forum topic | other blogs | 12823 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Depends on what you mean by "Actors model"

The classic Actors model (ala Hewitt, and later Agha) to which the paper refers does indeed have only asynchronous message passing. However, synchronization can be emulated by pairs of asynchronous messages, and some implementations of the Actors model seem to include syntactic sugar for such situations.

The difference between reactive objects and actors with regard to undefined methods seems to be the following: depending on its state, an actor may only respond to some subset of its full set of methods at any given time (the remainder of the methods being "undefined" at that time, and calls to those methods being queued); in contrast, reactive objects will always respond to all methods, no matter what its internal state.

By Allan McInnes at Fri, 2007-04-20 00:06 | login or register to post comments

Bounded Buffers

The difference between reactive objects and actors with regard to undefined methods seems to be the following: depending on its state, an actor may only respond to some subset of its full set of methods at any given time (the remainder of the methods being "undefined" at that time, and calls to those methods being queued); in contrast, reactive objects will always respond to all methods, no matter what its internal state.

This is a great explaination. An example using a bounded buffer as an actor accepts both the messages "put" and "get", but not in all states. If the buffer is empty and A sends "get" a third party will have to send "put" in order for A to get the reply and proceed.

This kind of selective behaviour based on state, as you clearly describe, is not possible in Timber.

By Peter A Jonsson at Fri, 2007-04-20 11:06 | login or register to post comments

In the context of CSP I've

In the context of CSP I've heard this style described as "I communicate, therefore I synchronize." (I must read about actors one day.)

By Luke Gorrie at Sat, 2007-04-21 07:37 | login or register to post comments

Thanks for the illustration.

Thanks for the illustration. I was getting confused by the term 'undefined' which I was automatically reading to mean 'an undefined method/message' as opposed to 'undefined behaviour depending on current state'. Poor reading on my part!

By Oliver Mooney at Mon, 2007-04-23 14:40 | login or register to post comments

Tripped me up too

Yep, that tripped me up on a first reading too. It took me a little while to see what it was they were getting at.

By Allan McInnes at Mon, 2007-04-23 15:20 | login or register to post comments