I'm thinking of formalizing verification of the Stop message in next rev of AF

[Brainstorms]

I.e., "Stop" means "Stop", and "Stop" does not mean "Start shutting down".  Which is what I've been trying to get at in my earlier posts...

[AristosQueue (NI)]

Brainstorms wrote:

I.e., "Stop" means "Stop", and "Stop" does not mean "Start shutting down".  Which is what I've been trying to get at in my earlier posts...

Almost. Stop means stop from the point of view of the caller. Stop means start shutting down from the point of view of the actor receiving the Stop message. That's the abstraction I'm trying to provide.

[drjdpowell]

AristosQueue wrote:

Just because you've told some subsystem to shutdown doesn't mean your caller gets to stand there and wait for that shutdown to complete... it's got other things to be doing (after all, it might not be the whole application that is shutting down, just one little piece).

Does it?   What if the subsystem shut takes on the order of 10-100ms, and that isn't that long for the Caller to be unresponsive?   And what if that subsystem shutdown involves multiple significant steps, each of which can potentially change how messages would have to be processed (and thus is a separate state)?  The ability to "turn off" full asynchronous message handling temporarily during major (but quick) restructuring can reduce the bloat of state logic.

[AristosQueue (NI)]

I know of one customer where the shutdown sequence for one nested actor takes minutes as it retracts various hydraulics. That's a long time for the caller to be unresponsive.

[Brainstorms]

I'm having a hard time reconciling #53 with #51...

From the point of view of the caller, the hydraulics nested actor "stopped" when it was issued the Stop Message.  From the point of view of the nested actor, it's got minutes of life left controlling/overseeing the hydraulics retracting.

What if there's a problem, a hazard, a need to recall, a system failure, an operator who changed his mind, something that moved into the path of & blocked the retraction motion, etc, et al, and so forth during the many minutes that this is being done?

From the point of view of the caller, it's a done deal.  Dead & gone.  No need for messaging.  From the point of view of the nested actor, it's not done and the shutdown needs to be aborted, modified, retried, paused temporarily, etc, et al, and so forth...  But it can't do what's needed because "the rest of the world thinks it's dead".

This brings me back to considering that what the framework needs is a "Shutdown Message" to go with the "Stop Message".  The hydraulics would be messaged with Shutdown Message, and if successful after its many minutes of retraction, would message its caller with a "Shutdown Complete" message.  Then the caller, knowing that the retraction, etc. is done, would message the nested actor with a Stop Message.  And the nested caller's actor tree would then rapidly and without other activity (messaging) collapse from the leaves upward until the entire stop is complete and the actor processes are cleared -- quickly (by comparison).

The only other consideration for the framework is the possibility of changing the message handling during the now-formalized shutdown state.

[ian.yeager]

To be clear, “this” framework needs a Shutdown message to go along with the stop message. Not all frameworks need that. Like I said in my other post, if this functionality was built into the AF at best, I would have to ignore it on some projects and at worst create code to work around it, depending on how it’s implemented.

[Brainstorms]

Ian, you're arguing for removing Batch Message, Reply Message, Time-Delayed Message, et al -- precisely because "not all frameworks need those, either". 

Some would argue that a far larger percentage of applications need to shut down cleanly than need to send batch messages, etc.

[AristosQueue (NI)]

> I'm having a hard time reconciling #53 with #51...

I request that you accept that it is real and move on. It's the most extreme case of a pretty standard scenario. It's a valid use case.

JDPowell: It just occurred to me to ask: how in hell do you make a synchronous call to the asynchronous process you're shutting down? I've seen your actors. There's no synchronous interface to your actors. Are you talking just a reply msg just to stall that caller actor while the nested actor goes about its business? And the nested actor just doesn't post the reply until it is actually finished?

[kegghead]

I've handled the synchronization through a callback mechanism. Message delivery includes an object which is signalled through some means after the message is processed. The sender blocks on the signal.

[AristosQueue (NI)]

kegghead:

That's exactly what I just described. 🙂 

-- Stephen