Is it possible to have an event or callback based on a different VI's execution state?

[Mr._Jim]

Alright, here's a fun and challenging question for someone out there:

Here's my scenario:

I have two VIs.

1. A custom error handler VI that is called numerous times throughout my code.  Its use case is equivalant to the stock NI error handlers off of the UI palette.

2. An error handler server that runs as a daemon in the background.  This daemon is quietly launched when an instance of my error handler (above) encounters an error.  It continues running until all callers of the error handler VI stop executing.

I'd like to shut down the daemon when all callers of my error handler VI (item 1) stop executing.  Right now I poll periodically to check the execution state of each caller VI.  When all of the callers' execution states are something other than "Running", I stop the error handler server.

I'm looking for an event-based solution that either triggers an event or callback when each caller VI stops executing.  Can anyone think of a way to do this?  I'd like to get away from polling, as it can be costly when there are a lot of callers, as is often the case in large applications.

I'd be very grateful if someone can figure out a way to do this.  Maybe LAVA would be a better bet, but I thought I'd try here first!

Thanks in advance,

Mr. Jim

[tst]

I don't know of any mechanism in LV which currently gives you the hooks to get execution state change events on arbitrary VIs. I think the DETT has hooks for it, but those are not publicly exposed (you could try asking someone at NI privately, if you know the right people). XControls can do it, but that requires placing them in the VI. XNodes might have the ability, but they're not supported.

A couple of options which might simplify your life (or not) would entail decoupling the daemon's lifespan from that of the callers:

1. Load and unload it explicitly at the start and end of the app. Great if you have a structured app, but not so much if you want something more free form.
2. Unload it as soon as it's done doing its work (or after a timeout from the last action it took).

[Mr._Jim]

Thanks, tst.  I wasn't holding my breath on this one.

Hmm...  I hadn't thought of XControls!  I'd rather not go that route, though, in the interest of keeping the error handler code as light as possible.  (In the daemon itself I don't mind more complexity)  If I did that, the cure might be more expensive than the problem it solves.

---

tst wrote:

1. Load and unload it explicitly at the start and end of the app. Great if you have a structured app, but not so much if you want something more free form.
2. Unload it as soon as it's done doing its work (or after a timeout from the last action it took).

---

Sadly, this app is rather "free form".  It has a lot of multi-threaded, asynchronous operations since I'm performing parallel TCP communication to several hosts. Each dynamically called VI calls the error handler.

Option 2 might be a decent idea, though.  If I went with that, I'd just have to tweak the architecture accordingly.  It may well be the most feasible solution.

Thanks for the quick reply!