actor confusion, react method does not return???? huh?

ah, okay, I found 50% of the answer......all the material I have been
reading is trying to make it easier by saying it doesn't return which
made it way harder for me to understand. In reality, the
implementation of react grabs the next message and processes it and
throws an exception and loop has special handling to or something to
allow this.

I am still not sure I get 100% of it yet though as in this example
code
act() {
react{
act()
}
}

To make this work under the covers, I call act which calls react which
I think is really just registering the block of code and it seems then
that once my code is sent a message, I must be deregistered from
listening so I must call act() to reregister....IS THIS how it
works???

In the case of using loop though I am a bit more confused...
act() {
loop {
react{
}
}
}

Here I am a bit more confused....loop must be registering something to
know that after every react call, it needs to call act again, or???? I
can't quite put the sequences together for how this would be
implemented.
thanks,
Dean

On Jul 26, 9:00 am, deanhiller wrote:
> I keep reading "react never returns".  receive makes complete since in
> that a Thread will be consumed by that one actor for the receive case.
>
> In the case of react though, I would think react is passing the block
> of code as a partial function to some entity that keeps references to
> all actors and then react returns control back to the thread that
> called it....ie. it returns, and it seems more like it is that react
> only registers a single listener which is deregistered as soon as the
> message is processed which is why you either have to do
>
> act() {
>   loop {
>      react{}
>    }}
>
> OR
> act() {
>      react{
>         act()
>      }
>
> }
>
> Something doesn't make since to me though as my thread stack if it
> calls react and it truly did not return, then if I had a main thread
> and I called act on that main thread which then called react, my
> thread would be stuck, wouldn't it.  What exactly do they mean it
> doesn't return.
>
> In all things said, I really don't get why the while(true) doesn't
> work and loop does.  Is there some article that delves into a lot more
> detail(even threads behind the framework and how it precisely works)
>
> A function not returning implies the thread is stuck and I just can't
> seem to get passed this.  It would seem more logical to call a
> function that does return to register the code that will be run on any
> thread when a message comes in to me.
>
> thanks for any info on this,
> Dean

Dean,

to be honest, take a look at Akka Actors.

Cheers,
√

On Tue, Jul 26, 2011 at 5:43 PM, deanhiller <dean.hiller@gmail.com> wrote:

ah, okay, I found 50% of the answer......all the material I have been
reading is trying to make it easier by saying it doesn't return which
made it way harder for me to understand.  In reality, the
implementation of react grabs the next message and processes it and
throws an exception and loop has special handling to or something to
allow this.

I am still not sure I get 100% of it yet though as in this example
code
act() {
    react{
       act()
    }
}

To make this work under the covers, I call act which calls react which
I think is really just registering the block of code and it seems then
that once my code is sent a message, I must be deregistered from
listening so I must call act() to reregister....IS THIS how it
works???

In the case of using loop though I am a bit more confused...
act() {
   loop {
      react{
      }
   }
}

Here I am a bit more confused....loop must be registering something to
know that after every react call, it needs to call act again, or???? I
can't quite put the sequences together for how this would be
implemented.
thanks,
Dean

On Jul 26, 9:00 am, deanhiller <dean.hil...@gmail.com> wrote:
> I keep reading "react never returns".  receive makes complete since in
> that a Thread will be consumed by that one actor for the receive case.
>
> In the case of react though, I would think react is passing the block
> of code as a partial function to some entity that keeps references to
> all actors and then react returns control back to the thread that
> called it....ie. it returns, and it seems more like it is that react
> only registers a single listener which is deregistered as soon as the
> message is processed which is why you either have to do
>
> act() {
>   loop {
>      react{}
>    }}
>
> OR
> act() {
>      react{
>         act()
>      }
>
> }
>
> Something doesn't make since to me though as my thread stack if it
> calls react and it truly did not return, then if I had a main thread
> and I called act on that main thread which then called react, my
> thread would be stuck, wouldn't it.  What exactly do they mean it
> doesn't return.
>
> In all things said, I really don't get why the while(true) doesn't
> work and loop does.  Is there some article that delves into a lot more
> detail(even threads behind the framework and how it precisely works)
>
> A function not returning implies the thread is stuck and I just can't
> seem to get passed this.  It would seem more logical to call a
> function that does return to register the code that will be run on any
> thread when a message comes in to me.
>
> thanks for any info on this,
> Dean

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Hi Dean,
In our book ("Actors in Scala", Artima: http://www.artima.com/shop/actors_in_scala) we have a chapter devoted to react and event-based programming (Erlang-style) in general.
If you don't need an Erlang-style receive/react, you should consider using Akka's actors, which are also covered in our book.

ah, okay, I found 50% of the answer......all the material I have been
reading is trying to make it easier by saying it doesn't return which
made it way harder for me to understand.  In reality, the
implementation of react grabs the next message and processes it and
throws an exception and loop has special handling to or something to
allow this.

Yes, after processing the next message, react throws a control exception which unwinds the stack of the current (worker) thread. That's why no code is run after invoking react. This also means that while loops don't work, because the control exception would propagate out of the body of the while loop.
The loop combinator works by intercepting control exceptions in a way that allows it to run its next iteration after the previous react has finished.

I am still not sure I get 100% of it yet though as in this example
code
act() {
    react{
       act()
    }
}

To make this work under the covers, I call act which calls react which
I think is really just registering the block of code and it seems then
that once my code is sent a message, I must be deregistered from
listening so I must call act() to reregister....IS THIS how it
works???

Yes, exactly. Once your actor starts processing a message, the block of code passed to react is deregistered. That's why you have to call act recursively or use loop in this case.
Note that messages are always processed on an empty stack. That's why it is not harmful to loop indefinitely using recursive method calls like in the above code.

In the case of using loop though I am a bit more confused...
act() {
   loop {
      react{
      }
   }
}

Here I am a bit more confused....loop must be registering something to
know that after every react call, it needs to call act again, or???? I
can't quite put the sequences together for how this would be
implemented.

As I mentioned before, loop arranges things so that the control exception thrown by react is caught, and the body of loop is started again.
Cheers, Philipp

On Jul 26, 9:00 am, deanhiller <dean.hil...@gmail.com> wrote:

I keep reading "react never returns".  receive makes complete since in

that a Thread will be consumed by that one actor for the receive case.

In the case of react though, I would think react is passing the block

of code as a partial function to some entity that keeps references to

all actors and then react returns control back to the thread that

called it....ie. it returns, and it seems more like it is that react

only registers a single listener which is deregistered as soon as the

message is processed which is why you either have to do

act() {

  loop {

     react{}

   }}

OR

act() {

     react{

        act()

     }

}

Something doesn't make since to me though as my thread stack if it

calls react and it truly did not return, then if I had a main thread

and I called act on that main thread which then called react, my

thread would be stuck, wouldn't it.  What exactly do they mean it

doesn't return.

In all things said, I really don't get why the while(true) doesn't

work and loop does.  Is there some article that delves into a lot more

detail(even threads behind the framework and how it precisely works)

A function not returning implies the thread is stuck and I just can't

seem to get passed this.  It would seem more logical to call a

function that does return to register the code that will be run on any

thread when a message comes in to me.

thanks for any info on this,

Dean

-- Co-author, "Actors in Scala" (Artima Inc, 2011) Postdoc, EPFL and Stanford University

thanks!!!! that makes sense.

On Jul 26, 10:50 am, Philipp Haller wrote:
> Hi Dean,
>
> In our book ("Actors in Scala", Artima:http://www.artima.com/shop/actors_in_scala) we have a chapter devoted to react and event-based programming (Erlang-style) in general.
>
> If you don't need an Erlang-style receive/react, you should consider using Akka's actors, which are also covered in our book.
>
> ah, okay, I found 50% of the answer......all the material I have been
> reading is trying to make it easier by saying it doesn't return which
> made it way harder for me to understand.  In reality, the
> implementation of react grabs the next message and processes it and
> throws an exception and loop has special handling to or something to
> allow this.
>
> Yes, after processing the next message, react throws a control exception which unwinds the stack of the current (worker) thread. That's why no code is run after invoking react. This also means that while loops don't work, because the control exception would propagate out of the body of the while loop.
>
> The loop combinator works by intercepting control exceptions in a way that allows it to run its next iteration after the previous react has finished.
>
> I am still not sure I get 100% of it yet though as in this example
> code
> act() {
>     react{
>        act()
>     }
>
> }
>
> To make this work under the covers, I call act which calls react which
> I think is really just registering the block of code and it seems then
> that once my code is sent a message, I must be deregistered from
> listening so I must call act() to reregister....IS THIS how it
> works???
>
> Yes, exactly. Once your actor starts processing a message, the block of code passed to react is deregistered. That's why you have to call act recursively or use loop in this case.
>
> Note that messages are always processed on an empty stack. That's why it is not harmful to loop indefinitely using recursive method calls like in the above code.
>
> In the case of using loop though I am a bit more confused...
> act() {
>    loop {
>       react{
>       }
>    }
>
> }
>
> Here I am a bit more confused....loop must be registering something to
> know that after every react call, it needs to call act again, or???? I
> can't quite put the sequences together for how this would be
> implemented.
>
> As I mentioned before, loop arranges things so that the control exception thrown by react is caught, and the body of loop is started again.
>
> Cheers,
> Philipp
>
> On Jul 26, 9:00 am, deanhiller wrote:
> I keep reading "react never returns".  receive makes complete since in
> that a Thread will be consumed by that one actor for the receive case.
>
> In the case of react though, I would think react is passing the block
> of code as a partial function to some entity that keeps references to
> all actors and then react returns control back to the thread that
> called it....ie. it returns, and it seems more like it is that react
> only registers a single listener which is deregistered as soon as the
> message is processed which is why you either have to do
>
> act() {
>   loop {
>      react{}
>    }}
>
> OR
> act() {
>      react{
>         act()
>      }
>
> }
>
> Something doesn't make since to me though as my thread stack if it
> calls react and it truly did not return, then if I had a main thread
> and I called act on that main thread which then called react, my
> thread would be stuck, wouldn't it.  What exactly do they mean it
> doesn't return.
>
> In all things said, I really don't get why the while(true) doesn't
> work and loop does.  Is there some article that delves into a lot more
> detail(even threads behind the framework and how it precisely works)
>
> A function not returning implies the thread is stuck and I just can't
> seem to get passed this.  It would seem more logical to call a
> function that does return to register the code that will be run on any
> thread when a message comes in to me.
>
> thanks for any info on this,
> Dean
>
> --
> Co-author, "Actors in Scala" (Artima Inc, 2011)
> Postdoc, EPFL and Stanford University