actors: getting an ActorRef to self

[Aaron VonderHaar]

What is the normal way to get an ActorRef to yourself?  (Or is this generally avoided?)  I'm not sure how to get `refToSelf` in the code below.

Does such an actor need to be given the ActorThread to do this?  It seems like that should only be necessary if it needs to spawn new actors.  (And even then, I'm guessing it's probably bad to bind an object more than once with `bindActor`)

public class DefaultService implements Service {
  public void doWork(ActorRef<Listener> listener) {
    doWorkInternal();
    ActorRef<Service> refToSelf = ???;
    listener.tell().workFinished( refToSelf );
  }
}

and I'm setting up the system like this:
 
{
  ActorRef<Service> service = actorThread.bindActor(Service.class, new DefaultService)
  ActorRef<Listener> listener = actorThread.bindActor(Listener.class, new Listener() { ... });
  service.tell().doWork(listener);
}

Thanks for any input.

--Aaron V.

[Aaron VonderHaar]

After digging into the code, I see that `bindActor` makes a proxy that
simply packages up calls into message objects and then sends them to
the queue of the associated ActorThread (meaning the ActorThread is
responsible for synchronization, not the proxies). I guess this means
that it should work if you bind an actor multiple times, as long as
you always bind it to the same thread.

So I suppose I could pass my DefaultService an ActorThread and let him
create an ActorRef to himself. This feels ugly, and also is
potentially error-prone since you have to make sure that you never
bind the same actor to multiple threads at once. But I'll give it a
try.

If I don't like how that turns out, I'm thinking I might try putting
together a patch that would store the currently-executing ActorRef in
thread-local storage and make it accessible as `static Actors.self()`
or something like that.

Cheers,
--Aaron V.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Jumi: common test runner for the JVM" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jumi-test-runn...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
--Aaron V.
[ http://github.com/avh4 ]

[Esko Luontola]

Aaron VonderHaar wrote on 25.11.2013 2:42:
> After digging into the code, I see that `bindActor` makes a proxy that
> simply packages up calls into message objects and then sends them to
> the queue of the associated ActorThread (meaning the ActorThread is
> responsible for synchronization, not the proxies). I guess this means
> that it should work if you bind an actor multiple times, as long as
> you always bind it to the same thread.
>
> So I suppose I could pass my DefaultService an ActorThread and let him
> create an ActorRef to himself. This feels ugly, and also is
> potentially error-prone since you have to make sure that you never
> bind the same actor to multiple threads at once. But I'll give it a
> try.

Yes, that's how I've been doing it this far.

> If I don't like how that turns out, I'm thinking I might try putting
> together a patch that would store the currently-executing ActorRef in
> thread-local storage and make it accessible as `static Actors.self()`
> or something like that.

Sounds like a good idea. I've tried to avoid thread-locals, because they
are one type of global state, but in this case that might be justifiable.

--
Esko Luontola
www.orfjackal.net

[Esko Luontola]

Something to think about is that would it be better to provide access to the current ActorRef or ActorThread or both. An actor object can be wrapped inside proxies and adapters, so it's not always obvious to the code using "Actor.selfRef()" that what it would point to. Also the generic type parameter of the ActorRef could not be known.