Compute result and return result, but don't stay around

[Jonathan Rochkind]

So I have an Actor which maybe has been doing a bunch of stuff.

But then someone sends the message, let's call it
#.async.finish_computation .

At this point, the Actor should execute a potentially long-running
computation, and the computed result should be available to anyone who
might want to know it, but after it's been computed the Actor should
shut down (#terminate), the actor will no longer be called upon to do
anything again (except give the computed answer).

I am not sure if I am succesfully explaining this clearly... but the
trick is that the Actor should terminate itself, BUT still somehow be
available to return the value of the computed result to those who ask
for it. That is, it should terminate, without knowing if 0 or more
people will later need the value of the computation. But of course, once
it's actually terminated, nobody else can ask it for the value of the
computation, but that won't work.

It could wait until someone asks for the value of the computation, and
then self.terminate -- but ideally it would still terminate even if
nobody ever asked for the vlaue of the computaton (to avoid thread
leak), and also support more than 1 ask for the value of the
computation. It's terminated, but can still somehow supply the value.

Does this make any sense at all? What's the proper design to be able to
accomplish this: Go off and do a bunch of work, and then make the
computed value available somehow, but then terminate to avoid thread
leak, because you're done.

Thanks for any ideas!

[Tim Carey-Smith]

So you'd like the the internal state of the actor to somehow be maintained after the actor has been terminated?
Have you consider subscribing or having a future connected to the "compute" actor?

A related example could be: https://github.com/halorgium/celluloid-multiplex

In general, you should decide on the contract that this actor provides.
I do not think you should support optional retrieval at a later point.
Without having some event to determinate the result has been retrieved, you won't very easily be able to terminate.
Of course, you could use a timer, but that is never a good idea :)

Ciao,
Tim

>
> Thanks for any ideas!
>
> --
> You received this message because you are subscribed to the Google Groups "Celluloid" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to celluloid-rub...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ben Langfeld]

I would suggest you're taking the wrong approach. A better one might be "compute the value and then put it *here*". Alternatively, a future may survive the actor it was executed in...

Regards,
Ben Langfeld

[Tim Carey-Smith]

A future does store the value, and can be interrogated after the actor is dead.
You'll still need somewhere to store that future reference though.

Ciao,
Tim

[Tony Arcieri]

Note that once the value has been calculated (via a future) you should be able to call async.terminate prior to returning the value to automatically shut the actor down. The value will be persisted in the future.

Tony Arcieri

[Jonathan Rochkind]

Okay, thanks for the advice, Ben and Tim.

I'll have to rethink it, I guess. There's no obvious/easy place 'here'
to put the result for later retrieval (it would probably have to be
another actor), but maybe with some rethinking it could be refactored
that way.

Ah, but if a future can still be interogated after the actor is dead,
that might work fine. I do have somewhere to store the future and ask
for it (it's just not currently an Actor itself, and not something the
individual Actors know about, the caller context).

Let's see...

Nice, that does work! If you have a future already, you can indeed ask
for it's #value even if the original Actor it was based on has
terminated. That will in fact work perfectly for me. This, that a future
keeps working even after the actor is dead, is an intentional part of
the API, not an accident of implementation likely to change in the, er,
future?

On 5/13/2013 6:10 PM, Ben Langfeld wrote:
> I would suggest you're taking the wrong approach. A better one might be
> "compute the value and then put it *here*". Alternatively, a future may
> survive the actor it was executed in...
>
> Regards,
> Ben Langfeld
>
>

> On 13 May 2013 18:57, Tim Carey-Smith <g...@spork.in <mailto:g...@spork.in>>

> wrote:
>
> On May 14, 2013, at 9:44 AM, Jonathan Rochkind <roch...@jhu.edu

> <mailto:celluloid-ruby%2Bunsu...@googlegroups.com>.

> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "Celluloid" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to celluloid-rub...@googlegroups.com

> <mailto:celluloid-ruby%2Bunsu...@googlegroups.com>.

[Jonathan Rochkind]

On 5/13/2013 7:49 PM, Tony Arcieri wrote:
> Note that once the value has been calculated (via a future) you should
> be able to call async.terminate prior to returning the value to
> automatically shut the actor down. The value will be persisted in the
> future.

Yep, this in fact ends up perfect for me. Caller takes out a future on
the value. Actor computes the value then self.terminates. Caller can
then call future.value at some future point, 0, 1, or many times -- in
any of those cases, value is available, and Actor is succesfully
terminated. Perfect!

While not actually relevant for the particular use case I have, this
makes me think of another question too -- are Celluloid futures
themselves thread-safe? Can a single future object be shared amonst
multiple threads (which aren't neccesarily actors, may be straight ruby
threads), and they all call #value on it non-synchronized, and will that
be okay? Just curious.

Jonathan

[Tony Arcieri]

On Tue, May 14, 2013 at 6:57 AM, Jonathan Rochkind <roch...@jhu.edu> wrote:

While not actually relevant for the particular use case I have, this makes me think of another question too -- are Celluloid futures themselves thread-safe?  Can a single future object be shared amonst multiple threads (which aren't neccesarily actors, may be straight ruby threads), and they all call #value on it non-synchronized, and will that be okay?  Just curious.

Yes 

--
Tony Arcieri