While any object can be sent as a user-level message between Actors,
the convention is that instances of
ActorRequest are the only kind
of user-level message exchanged.
ActorRequest (a “request”) is a triple of a
for a remote behavior (the “message”), a
Process interested in the
reply (the “sender”), and a
Promise by which the reply is to be
delivered to the
Process (the “promise”).
The sender is not always an
ActorProcess. An ordinary
ActorRequests and can wait for eventual replies or exceptions.
A request is not intrinsically targeted at any actor in particular; it does not store any information about the identity of its target.
If the promise is
nil, the request is asynchronous and no-one cares
about the reply to the eventual evaluation of the message. However,
even in this case, the sender is almost always non-nil: an
asynchronous request can still usefully have a notion of “sender”
associated with it.
Requests can be sent to an actor with
ActorRequest >> #sendTo: or
#redirectTo: family of methods. There are also convenience
Actor class >> #sendRequest:to: and
and of course any instance of
ActorProxy builds and sends
Once a request has been sent, its reply may be retrieved via the
Promise it holds.
Sending replies or notifying of failures
Ultimately, when a response is ready for a request, it is transmitted
ActorRequest >> #resolveWith: or
appropriate. Compare these to similar and similarly-named methods on
In order to ensure that every request receives an answer, a request
sometimes stores the identity of an
Actor (in its
variable) that has taken responsibility for the request, so that it
can send a default answer if no-one else supplies anything first. The
request object takes care to signal the
worker whenever someone
supplies a reply to it, so that the
worker knows it no longer needs
to bother with the request.