You can stop the helper loop immediately if you want by adding a "sentinel" element. For example, say your queue data type is a string containing a database query. You know that no valid query will ever be an empty string, so you check for an empty string each time you dequeue something. If it's empty, stop the loop, otherwise wait on another element. This keeps your AF message queue separated, and in Stop Core you can send the sentinel value to the Dequeue function. Or I suppose you could just release the queue, then catch the error in your helper loop.
This seems to achieve identical functionality as the stop notifier you mentioned earlier, right?
You can stop the helper loop immediately if you want by adding a "sentinel" element. ...
Channel wires have an actual dedicated feature to do this sort of thing but I haven't used those yet. I hear good things.
Huh, I wasn't aware of that functionality within channels. You talking about this (link)?
It's the same overall functionality, I'm just saying you don't need both a notifier AND a queue. I've used notifiers before if I'm doing something like DAQmx that needs to be written over and over again. If I already have a queue, I don't need to add the notifier as well- I can do it with just the queue.
And I think that's the feature, yes. I thought it was called "Last write" or something but it seems like that's the one I was remembering. I've never used it myself.
So @drjdpowell, your suggestion for an implementation might this then:
1. queries are sent to a helper loop via a queue
2. helper loop checks for stop notifier each time
3. If a "priority" query comes up, load this into the helper loop queue at the front of the line
My motivation in these discussions about seemingly simple techniques is often the "hidden complexity" they can introduce. And "enqueuing on front" for "priority" is an example of that. Enqueue on front has hidden complexity in that multiple "priority" messages will have indeterminate execution order. Put A, then B on the front of this queue and you do not know if they will execute A then B or B then A. One of those orderings might cause a bug, yet happen rarely enough that you will not notice it in testing and deploy buggy code. The worst possible bug.
Here's a better, seemingly more complicated but actually simple option. It takes advantage of the fact that a Helper Loop has only one Writer sending it messages (don't use this suggestion with Actor Message Queues!):
3. When any task comes in:
This is actually simple, in use, as it preserves message ordering of tasks of the same priority. AB is always AB; no race condition. It's also a more powerful design, as you can have multiple priority levels, or do things like cancel individual tasks.