From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
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.
@WavePacket wrote:
@OneOfTheDans wrote:
Option 3 -- when a request happens, your Caller Actor launches a new Nested Actor that does one slow item in the background...
So this suggestion interests me, particularly since my implementation is for a database which supports concurrent communication. If I have X queries to run to run, is there really a reason that I couldn't launch X copies of the nested actor and then have them all run in parallel?
I'll also have to face the question of who should be shutting down the database actor(s). Does the database actor shut itself down after sending the query result, or should the callee manage how many copies are alive. I haven't had to face the music on that type of question before.
The particulars will depend on your exact database setup and processing power, but I bet there's a balance between parallel queries and serial ones. You could do some benchmarking to figure that out.
Shutting down the actors depends on how long they're active and what the init/deinit is. Some thoughts to consider:
-If an actor only lives to launch, do a single query, then die, do you need an actor? Just use an async subVI with an enqueuer input. An actor works too of course.
-If you want your actors to persist, I'd try to benchmark your system and decide on a number of actors to use. Create another intermediate actor to manage message routing and actor life ("Database actor manager") which can launch n actors, then submit each new query to the next one in the list.
There's no single right answer for single-use vs. long-term actors. I've used both. Single use are generally easier to use since they don't have a state and get wiped each time you use them, but they are usually slower since you have to acquire resources on each call.
I don't use them much either to be honest, but the pro to using a VI is that there is very little overhead and it's very easy to debug. It just launches and there ya go. If you're already set up in AF then you can use an actor this way but it's a little bigger since you need to make an Actor class and either override Actor Core or create at least a single message. It is nice that you can put initialization stuff in Pre launch init and know whether or not it got the resource right away.
I just wanted to throw it out there. I know when I'm in an AF project I tend to want to make EVERYTHING an actor, and often that's just needless overhead if a function just needs to be called and then return. I don't think there's any harm to using it this way.
Don't forget though- no matter which way you choose, make sure the VI that's interacting with the DB is set to reentrant. Non-reentrant VI's will be shared amongst actors and will serialize everything.
