Compute result and return result, but don't stay around
20 views
Skip to first unread message
Jonathan Rochkind
May 13, 2013, 5:44:20 PM5/13/13
to cellulo...@googlegroups.com
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!
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
May 13, 2013, 5:57:18 PM5/13/13
to cellulo...@googlegroups.com
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
May 13, 2013, 6:10:14 PM5/13/13
to cellulo...@googlegroups.com
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
Ben Langfeld
Tim Carey-Smith
May 13, 2013, 6:22:22 PM5/13/13
to cellulo...@googlegroups.com
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
You'll still need somewhere to store that future reference though.
Ciao,
Tim
Tony Arcieri
May 13, 2013, 7:49:13 PM5/13/13
to cellulo...@googlegroups.com
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
May 14, 2013, 9:54:56 AM5/14/13
to cellulo...@googlegroups.com
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>>
> <mailto:celluloid-ruby%2Bunsu...@googlegroups.com>.
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
>
>
> > 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>.
> >
> >
>
> --
> 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
Jonathan Rochkind
May 14, 2013, 9:57:08 AM5/14/13
to cellulo...@googlegroups.com, Tony Arcieri
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
> 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.
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
May 14, 2013, 10:30:39 AM5/14/13
to cellulo...@googlegroups.com
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
Reply all
Reply to author
Forward
0 new messages