Handling "priority" message in actor framework

[drjdpowell]

---

@WavePacket wrote:

---

---

So specifically I'm creating an actor that sends queries off to a database. I'm planning on queuing up a bunch of background tasks which I'm not all that interested. However, if the user asks for something from the database, I do want to display that right now.

So my thought was to maintain two helper loops which could open two connections to the database. One of those loops would handle all the background stuff, and then the other one would run that priority query separately.

---

---

I do a lot of SQLite-based applications, and I would strongly suggest you have an actor, called something like "Database Viewer", that does the UI display stuff, totally separate from the Actor(s) that do other operations on the DB.  Then no actor has any "background stuff" that needs interrupting and I think you will find all actors are cleaner and simpler to write.  As an added benefit, your "Database Viewer" can, in addition to its primary use, be built into a separate "Viewer" app that can be used to view past data collected by the main application.

[drjdpowell]

Also, just to be devil's advocate, any use of "priority messages" is a code smell.  I would advise no-one to use priority messages ever, including for a so-called "emergency stop".  

[WavePacket]

---

@drjdpowell wrote:

Also, just to be devil's advocate, any use of "priority messages" is a code smell.  I would advise no-one to use priority messages ever, including for a so-called "emergency stop".  

---

Alright, you've pricked my annoyingly easy to poke curiosity.

For the moment (correct me here if I'm wrong) I'll presume that you are ok with implementing "priority" tasks like emergency stop somehow. What is your preferred implementation?

[WavePacket]

---

@drjdpowell wrote:

---

@WavePacket wrote:

---

---

So specifically I'm creating an actor that sends queries off to a database. I'm planning on queuing up a bunch of background tasks which I'm not all that interested. However, if the user asks for something from the database, I do want to display that right now.

So my thought was to maintain two helper loops which could open two connections to the database. One of those loops would handle all the background stuff, and then the other one would run that priority query separately.

---

---

I do a lot of SQLite-based applications, and I would strongly suggest you have an actor, called something like "Database Viewer", that does the UI display stuff, totally separate from the Actor(s) that do other operations on the DB.  Then no actor has any "background stuff" that needs interrupting and I think you will find all actors are cleaner and simpler to write.  ...

---

Just as a clarification, the "background" tasks I was referring too in that post were background database tasks. 

[WavePacket]

---

@BertMcMahan wrote:

...or you could just launch two actors and let AF handle the queues for you. Store one enqueuer as the "background" one and one as the "user" one. They can both open handles to the same database, assuming your toolkit supports it.

...

---

So far, this seems like the simplest option at the moment.

---

@BertMcMahan wrote:

Ah, good to know then!

So, cancelling operations can be done one of two ways. The first is to do it manually, and have any process periodically check to see if it needs to stop, then stop itself. For example, you could set up a Stop notifier, then at the beginning of each loop, run Wait on Notification with a timeout of 0. If there's a Stop notification there, it stops, otherwise it continues doing its thing. (There are a million ways to do this)....

---

Ah, in my mind I was being particular with "in process" (i.e. your "nuclear option"), the above suggestion feels more like "check if I can proceed."

There is a notification question though that I could ask, if I setup a notification and run Wait on Notification (link) with a timeout of 0 which executes before a notification has been sent out, I presume "notification" returns the default data types?

[drjdpowell]

---

@WavePacket wrote:

For the moment (correct me here if I'm wrong) I'll presume that you are ok with implementing "priority" tasks like emergency stop somehow. What is your preferred implementation?

---

First a question: your title says "priority message" but here you say "priority task"; why are you using those two different words interchangeably?

Also, what do you mean by "emergency stop"?  "High Voltage must be turned off within 100 ms of an arc being detected", is an example of an emergency stop.

[WavePacket]

---

@drjdpowell wrote:

---

@WavePacket wrote:

For the moment (correct me here if I'm wrong) I'll presume that you are ok with implementing "priority" tasks like emergency stop somehow. What is your preferred implementation?

---

...

Also, what do you mean by "emergency stop"?  "High Voltage must be turned off within 100 ms of an arc being detected", is an example of an emergency stop.

---

Emergency stop (in a software context) I guess I'd put as something that I want to software to do as soon as possible, even if the software has been told to do something else earlier and has not had the opportunity to finish those previous tasks.

---

@drjdpowell wrote:

---

@WavePacket wrote:

For the moment (correct me here if I'm wrong) I'll presume that you are ok with implementing "priority" tasks like emergency stop somehow. What is your preferred implementation?

---

First a question: your title says "priority message" but here you say "priority task"; why are you using those two different words interchangeably?

...

---

Probably because I'm green at this and don't keep my terminology straight :). I suppose proper AF coding is that messages are always handled immediately, but the tasks resulting from those messages could take time and have relative priorities?

[drjdpowell]

---

@WavePacket wrote:

---

@drjdpowell wrote:

---

@WavePacket wrote:

For the moment (correct me here if I'm wrong) I'll presume that you are ok with implementing "priority" tasks like emergency stop somehow. What is your preferred implementation?

---

...

Also, what do you mean by "emergency stop"?  "High Voltage must be turned off within 100 ms of an arc being detected", is an example of an emergency stop.

---

Emergency stop (in a software context) I guess I'd put as something that I want to software to do as soon as possible, even if the software has been told to do something else earlier and has not had the opportunity to finish those previous tasks.

---

@drjdpowell wrote:

---

---

First a question: your title says "priority message" but here you say "priority task"; why are you using those two different words interchangeably?

...

---

Probably because I'm green at this and don't keep my terminology straight :). I suppose proper AF coding is that messages are always handled immediately, but the tasks resulting from those messages could take time and have relative priorities?

---

Correct.  "Priority messages" come up because people make their message queue do double-duty as a job/task queue, but then find they don't read their messages within a reasonable time period.  

---

@WavePacket wrote:

---

@drjdpowell wrote:

Also, what do you mean by "emergency stop"?  "High Voltage must be turned off within 100 ms of an arc being detected", is an example of an emergency stop.

---

Emergency stop (in a software context) I guess I'd put as something that I want to software to do as soon as possible, even if the software has been told to do something else earlier and has not had the opportunity to finish those previous tasks.

---

 Ah, so not an emergency stop then; just "stop in a reasonable amount of time".  If you handle messages in a reasonable amount of time, then you don't need message priority.  Even if you have a long-running message, priority wont abort that message while it is executing, so message priority wont help.  You'll need some other technique, like the "Stop Notifier" suggested by Bert previously (which I have done on a few occasions).

[WavePacket]

Ok, so the previous reply was a bit long to quote. 

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

[BertMcMahan]

If you want to avoid using the AF queue for your messages, you can just enqueue new tasks at the front of your queue (Enqueue Element at Opposite End). That way they're immediately processed.

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.

Channel wires have an actual dedicated feature to do this sort of thing but I haven't used those yet. I hear good things.

---

@drjdpowell wrote:
Also, what do you mean by "emergency stop"? "High Voltage must be turned off within 100 ms of an arc being detected", is an example of an emergency stop.

---

You may know this already* so apologies if you do, but LabVIEW's built-in AF has an Emergency Stop message. It's implemented using priority queues. It doesn't abort messages in-progress, it just guarantees that the Stop message gets processed next. Personally I don't like this nomenclature. I view Estops the same way you do, but I wanted to let you know this was there since this terminology may be muddying the waters.

*(I know you wrote your own actor system so I don't know if you use NI's version much or not. I wanted to point out this, IMHO, poor choice of words for a specific type of priority message in NI's AF in case you weren't familiar with it.)