Ability to "soft" terminate

[tboyko]

It would be useful to be able to request that a cell terminate only once it is done with any work, whether that is pipelined or suspended methods. For instance:

cell.do_work("job 1")
cell.do_work("job 2")
cell.soft_terminate   # cell terminates once both jobs complete

Possible?

[halorgium]

There is an internal-ish API Celluloid::Actor.join which we could wrap to signal the actor to discard any new work and terminate when idle.

[tboyko]

That would certainly work for my uses...

[knewter]

@halorgium any suggestions on what a test case for this might look like? I have no idea how to write async tests yet :)

[knewter]

so @tarcieri @halorgium I know how to write a test for this with hilarious global variables and timers, but...seems very wrong.

[knewter]

So just documenting this. Here are the features I see:

1. If there are no outstanding jobs, calling #soft_terminate is the same as calling #terminate
2. If there are outstanding jobs, calling #soft_terminate will cause the actor to #terminate when the outstanding jobs are finished.
   • Attempts to add new jobs to this actor will raise an ActorSoftTerminatedError
   • Attempts to call #soft_terminate again will raise an ActorSoftTerminatedError

What else?

[tboyko]

@knewter Sounds good to me. Any additional functionality/service that I can think of can likely be achieved with existing mechanisms such as linking.

[halorgium]

@tbuehlmann could you perhaps provide some ideas based on our discussion today?

[tbuehlmann]

Hmm. Well, @knewter's feature set looks good. That's how I would want it, too.

[halorgium]

@tbuehlmann perfect.

[tboyko]

Looking forward to this feature. Any particular estimate as to when it will be completed?

[tarcieri]

I don't think it's actively being developed, and the semantics are somewhat involved

[tboyko]

@tarcieri Is the spec @knewter wrote not specific enough? I was hoping that @halorgium and @tbuehlmann indicated that development was underway but perhaps that isn't the case.

[tarcieri]

That spec is unfortunately nowhere close to comprehensive enough, and unfortunately, the terminology it uses doesn't match Celluloid's terminology, so it's hard to understand exactly what he's describing. The main problem is "what is a job?"

There are two things that need to be considered to know when an actor is "done":

• All outstanding messages in the mailbox have been processed
• All active tasks have completed

Unfortunately there are any number of things which can go wrong which will leave actors in a half-completed state, especially with this feature. An actor's mailbox may be empty, for example, but it has outstanding tasks waiting on messages.

Given how much trouble we've had trying to get the existing termination semantics correct, I'm pretty worried about implementing this feature at all.

I think a better approach might be to look into something like Akka's "dead letter mailbox"

[tboyko]

I see. Thank you for the clarification and point towards Akka's method.

On Apr 4, 2013, at 5:06 PM, Tony Arcieri notifications@github.com wrote:

That spec is unfortunately nowhere close to comprehensive enough, and unfortunately, the terminology it uses doesn't match Celluloid's terminology, so it's hard to understand exactly what he's describing. The main problem is "what is a job?"

There are two things that need to be considered to know when an actor is "done"

All outstanding messages in the mailbox have been processed
All active tasks have completed
Unfortunately there are any number of things which can go wrong which will leave actors in a half-completed state, especially with this feature. An actor's mailbox may be empty, for example, but it has outstanding tasks waiting on messages.

Given how much trouble we've had trying to get the existing termination semantics correct, I'm pretty worried about implementing this feature at all.

I think a better approach might be to look into something like Akka's "dead letter mailbox"

—
Reply to this email directly or view it on GitHub.

[halorgium]

@tboyko you should be able to push the semantics of what you need into your own app.
I would recommend you do this as @tarcieri and myself are concerned about introducing a feature which might introduce more confusion and instability regarding termination.

I will attempt to scrounge the example which @tbuehlmann worked with me on IRC.

[tboyko]

I'm already using actors with a singular exclusive method. My concern is to
not terminate an actor when it still has work in the queue. From my initial
tests, it seems that an actor.async.terminate achieves a poor-man version
of what I'm trying to achieve, letting the existing exclusive methods run
before terminating.

[halorgium]

@tboyko I am suggesting that you track the outstanding requests in your code.
Then when you trigger the terminate, you signal the actor and it will either terminate immediately or wait until all the requests are completed. It would also reject any new requests to start work.

[halorgium]

And by "trigger the terminate", I mean call a method which you have implemented on top.