A few questions (ok, a lot of questions) about some Actor methods

* the two exit methods - who calls these?  Can I call them on Actors I
have access to to "stop" them?  If I can't, how can I tell an Actor to
stop? What happens when these are called in the middle of processing a
message?

An actor should only call it's own exit method. When you want to tell an actor to stop from the outside, you can send the actor some "exit message" it expects, and it can then call exit in the course of message processing.
 

* link - what does this do and why would I do it? What does the link
that takes a function do?

When two actors are linked, a failure in one will propagate to any other actors linked to it. The other half of this equation is trapExit. If an actor traps exits, it will receive a message about the error in the linked actor; if not, the error will cause it to die as well, propagating out to it's links in turn. For more on this topic, I would recommend Joe Armstrong's "Programming Erlang". It's obviously a different language but the Actor model very close to that of Scala, and it's a fairly good treatment of error handling in actors.
 

* receive - what purpose does the version with the partial function serve?

The partial function (most typically a pattern-match) is the message-processing body.
 

* ! and forward - what is the difference?

Nothing besides the name.
 

* What does the partial function to !! do?

This allows you to "post-process" the response message. Something like:

val b = actor !! (Foo, {
  case Bar(bar) => bar
  case Baz(baz) => baz
})
 

* Bonus question: What is Channel for? It says it provides for "typed
communication", but I don't see how that isn't already possible with
Actors.

Although you can recover more specific types of messages by pattern matching on them, actors essentially speak in AnyRefs. There's no way to specify that a given actor should only receive messages of some type T. Channel provides a nice wrapper around an actor to do this. Unfortunately, I don't have any nice example handy of using them.
 

If there is a (scala-specific) reference point for this, that would
great, and I'm even willing to make a stab at updating the scaladoc.
I find the Odersky book great for introductory coverage, but I'm
baffled by this class (not to mention the myraid others in the
package, e.g. Debug).

Once again, I would recommend Armstrong's book (or at least the chapters on concurrency). It's not scala-specific, but the knowledge translates easily, and Erlang is one of the more mature languages with actor-based concurrency.

Hope that helps.

- Colin
 

MIME-Version: 1.0 --_b92deee5-ef06-4350-873f-94d34b985664_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > ! and forward - what is the difference? >=20 > Nothing besides the name. >=20 > - Colin This is not true. Sending a message to an actor via ! (bang) will cause the= "sender" to be the Actor object which sent the message. Sending an object = via forward does not override the original sender (assuming there was one).= the ability to forward messages is incredibly useful as the original sende= r can be sent responses by the ultimate receiver. =20 =20 _________________________________________________________________ Stay in touch with your friends through Messenger on your mobile http://clk.atdmt.com/UKM/go/174426567/direct/01/= --_b92deee5-ef06-4350-873f-94d34b985664_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable &gt=3B ! and forward - what is the difference?
&gt=3B
&gt=3B Nothing besides the name.
&gt=3B
&gt=3B = - Colin

This is not true. Sending a message to an actor via ! (bang)= will cause the "sender" to be the Actor object which sent the message. Sen= ding an object via forward does not override the original sender (assuming = there was one). the ability to forward messages is incredibly useful as the= original sender can be sent responses by the ultimate receiver.


Stay in touch with your friends through M= essenger on your mobile. Learn more. = --_b92deee5-ef06-4350-873f-94d34b985664_--

Thanks for the replies (and thanks to others as well)

Follow-ups below:

On Wed, Oct 21, 2009 at 8:02 AM, Colin Bullock wrote:
>
>> * the two exit methods - who calls these?  Can I call them on Actors I
>> have access to to "stop" them?  If I can't, how can I tell an Actor to
>> stop? What happens when these are called in the middle of processing a
>> message?
>
> An actor should only call it's own exit method. When you want to tell an
> actor to stop from the outside, you can send the actor some "exit message"
> it expects, and it can then call exit in the course of message processing.

I'm assuming such an "exit message" would, by convention, by the Exit
class/object?

So, given this, what is the difference between exit() and just getting
to the end of the act() method? Is it the only way to get out of
react()? (and if so, what is the point in creating an API for the
completion of a function call?)

>
>>
>> * link - what does this do and why would I do it? What does the link
>> that takes a function do?
>
> When two actors are linked, a failure in one will propagate to any other
> actors linked to it. The other half of this equation is trapExit. If an
> actor traps exits, it will receive a message about the error in the linked
> actor; if not, the error will cause it to die as well, propagating out to
> it's links in turn. For more on this topic, I would recommend Joe
> Armstrong's "Programming Erlang". It's obviously a different language but
> the Actor model very close to that of Scala, and it's a fairly good
> treatment of error handling in actors.

So, what constitutes a failure? An exception occuring?

>
>>
>> * receive - what purpose does the version with the partial function serve?
>
> The partial function (most typically a pattern-match) is the
> message-processing body.
Part of me feels stupid for not realizing this, as obviously, any
basic Actor code is using this. The other part of me feels like if
the scaladoc had an example, I would've put two-and-two together; I'm
still not making the mental leap that

def something(a:Any,b:Any)(c:PartialFunction)

means that are likely to do

something(a,b) {
}

Out of curiosity, why is this not a Function0?

>> * What does the partial function to !! do?
>
> This allows you to "post-process" the response message. Something like:
>
> val b = actor !! (Foo, {
>   case Bar(bar) => bar
>   case Baz(baz) => baz
> })

I'm not sure I follow. Do you have a more concrete use case for this?

I'm still unclear about Channel; I agree that it does what the
scaladoc and repliers say it does, but I don't see how; are there any
examples of this I can look at? I'm not even sure how one would use
the class at all. (I find this a frequent source of confusion in the
scaladocs).

Thanks again for the responses!

Dave