Actor Framework Discussions
Handling "priority" message in actor framework
Solved!
How exactly does your actor work? Does it receive a message, then do some processing on the data (which takes non-negligible time), then send a message somewhere else?
Since you say you're doing the grunt work in a helper loop, I don't think you need priority messages. Priority messages won't interrupt another message anyway; they just go to the front of the line. So if you have a message that takes a long time to process, a high priority message appearing won't stop the in-process one, it'll just be the NEXT one to fire when it's done.
If you are indeed doing the time consuming stuff in a helper loop, then your main message receiver (the Actor Core) will be responsive to "Hey this is an important message, process it now" messages anyway. It'll just need a way to either interrupt the helper loop to process right now or, if the helper loop only takes a little time to do each task, then perhaps it could just wait for the helper loop to be done with whatever it is it's working on.
I guess we could use a little more info about the architecture of the program. Where does the helper loop get its data if the user isn't actively sending it things? Are they automated messages or something?
You'd only need new Priority messages if, for some reason, a bunch of messages were already enqueued to your Actor and you needed to preempt them.
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).
Option two is the nuclear one- you simply abort the VI or process. You get a reference ahead of time, then if you need to stop it, you kill it. This is generally to be avoided since you will exit in an unknown state.
In your case, you're doing database calls. I assume each call takes some finite amount of time. If that's all your actor is doing, then I think I'd process each request within the message- as in, without a helper loop at all. If you add a helper loop, then you'll need some way to enqueue the database requests between the actor core and the helper loop, then you'll need to have a regular message send a Priority message to the helper loop (as in, enqueue at front of queue) to get the results right away. This sounds like more work than just letting the AF message queue handle that for you. Each message does one database query. If the user wants something now, send it as a priority message.
This will get you everything except for interrupting a current request. How long do these background requests take? Is it possible to just wait until the current one has finished? If not, you'll have to find a way to cancel the request. I don't do much with databases but basically your toolkit will need to let you cancel an active request, which might be a little hard to do.
Thus, we get to the last option, which you did mention- dual loops. You could do this one of two ways; either two helper loops, where one is the "fast" one and one is the "background" one, but you still need to implement internal queues, 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.
How long is each database request? How many user requests do you anticipate happening at once? Would two actors work? You can make them the exact same actor, just launched twice.
