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

[kegghead]

Yeah...  I really need to check out until I can pay this more attention. Sigh. Some days.

[drjdpowell]

AristosQueue wrote:

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?

Yes, all messages in my framework support replies, with the initial requestor having the option of receiving the reply asynchronously to a message-handler or through a blocking synchronous call.  Actually, there are possibilities that are in between these two extremes using NotifierMessengers or FutureTokens.  All my actors, as a rule, call "Reply" on all received Requests, when that Request is completed, even if there is no information needed to be sent in reply.  This is a callback mechanism like mje (sorry, kegghead) uses.

[drjdpowell]

ian.yeager wrote:

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.

To second ian.yeager's point, beware of trying to invent a system that handles all cases, as you may complicate the majority of simple cases while failing to adequately handle the complex ones.   Rather, I think you should handle to simple cases in a simple way, with the flexibitity to extend/replace as needed.

[drjdpowell]

AristosQueue wrote:

Another way that I've heard suggested to achieve this is for an actor to send a message to its nested actors saying, "Here's a new queue... use this to talk to me instead of the old one." Then close the old queue. Now the only actors who can message you is your own nested actors, so you assume that they'll only send you messages that are valid during shutdown because you've told them "you're now shutting down, too." Obviously, this would have to be baked into the Actor Framework since the caller queue is private data that no actor is allowed to modify.

I was thinking some more about why I like doing significant work synchronously, and it is that it is a great simplification to temporarily ignore the "outside world" (the Caller and anything the Caller has passed your Enqueuer to) and just deal with complex changes to the "inner world" (the Actor itself and the subactors it has launched) without outside interference.  Sort of like a lock about a critical code section. 

One could do a similar thing in the AF, without going synchronous, if the "outside" Enqueuer, that the Caller has, was identifiably different than the "inside" Enqueuer, that the Actor and subactors have, and if the Actor could tell the Message Queue (inside both Enqueuers) to temporarily deliver only "inside" messages.  This could be used during shutdown, but also during any complex (but quick) set of actions coordinated among the Actor and subactors.  "Outside" messages would be buffered up and delivered once the Actor unlocks its Message Queue.

What do you think?

[AristosQueue (NI)]

> What do you think?

I've played with exactly that idea, but I expect it to have a significantly deliterious effect on the speed of the queues to have to manage those refnum layers. Still worth exploring.

Your comments on synchronous are interesting. On further review, it might be a good idea. I could even make the change to the existing AF and have minimal concern about breaking existing apps. BUT, here's the one concern I have -- a nested actor synchronously sends Stop to its caller; caller, as part of stop core, sends a synchronous Stop message to its nested. Such an application would be weird, but it would work today, whereas tomorrow it would hang. So I'm not sure I can seamlessly drop this in without creating a new "Send Synchronous Stop VI", which I really want to avoid. Really.