How to get a top level application to detect a spawned task exit

[Mark Yedinak]

Without requiring the spawned task (subVI) to post a message to a queue, can the top level application that spawned the task detect that the subVI exited? That is, if the top level application opens a reference to a vi (using a VI template) and then runs it. When it runs it it doesn't wait for the VI to complete so it truly spawns a new task. I tried catching the spawned task's close using the Application Close and Panel Close events but neither detect the close. I know that I could have the subVI generate a user event or post a message to the queue but I was trying to catch the exit in an autonomous manner. I wanted to avoid having to pass anything to the subVI (the user event reference or queue name) as well as avoid the spawned task from knowing that it was invoked by another VI. In C when you fork a process you can catch the signal when it exits without the spawned task needing to do any special processing on it's exit. It would seem like we should be able to do this but so far I haven't found it.

[ShaunR]

Without requiring the spawned task (subVI) to post a message to a queue, can the top level application that spawned the task detect that the subVI exited? That is, if the top level application opens a reference to a vi (using a VI template) and then runs it. When it runs it it doesn't wait for the VI to complete so it truly spawns a new task. I tried catching the spawned task's close using the Application Close and Panel Close events but neither detect the close. I know that I could have the subVI generate a user event or post a message to the queue but I was trying to catch the exit in an autonomous manner. I wanted to avoid having to pass anything to the subVI (the user event reference or queue name) as well as avoid the spawned task from knowing that it was invoked by another VI. In C when you fork a process you can catch the signal when it exits without the spawned task needing to do any special processing on it's exit. It would seem like we should be able to do this but so far I haven't found it.

Check the "VI's in memory" list?

[Mark Yedinak]

Check the "VI's in memory" list?

This would imply polling. I don't want the top level application to poll. I would like to catch the close using an event structure.

[asbo]

This kind of involves a level of involvement I think you're looking to avoid, but you could try using a generic wrapper VI to call the actual subVI and signal the top-level VI in whatever manner you like. To use an event structure, I suppose you would have to pass something into the wrapper VI so that the top-level is aware of it as well.

[Mark Yedinak]

This kind of involves a level of involvement I think you're looking to avoid, but you could try using a generic wrapper VI to call the actual subVI and signal the top-level VI in whatever manner you like. To use an event structure, I suppose you would have to pass something into the wrapper VI so that the top-level is aware of it as well.

That would work because the generic VI could simply take the name of the actual VI you want to invoke and then have it wait for the VI to complete and then fire the event. However, I was hoping that LabVIEW would already provide a general method to allow calling VIs the ability to catch when a VI it spawned closed. This seems to be something missing which would be very useful for managing spawned tasks.

The caller can use the method "FP.Close" to cause the called subVI to exit. However, the reverse it not supported since it appears without extra effort the top level VI is unable to detect when a subVI closes.

[ShaunR]

You can attach your own "user event" on launch by using a callback function. I've only ever used it to hook the other VIs front panel controls' events, but it should be possible to hook the on-close event. You are still generating a User Event, but as the callback is attached to any VIs you launch yo'd only have to do it once, and you wouldn't have to write any code in the VI your are trying to hook.

Callbacks

[Ton Plomp]

Perhaps the 'VI will be purged' event is something you want?

Ton

[asbo]

For reference: VI will be purged. Didn't know about this one, I don't often muck with private stuff.

[ShaunR]

Thanks Shun. This is close but it still requires knowledge of the subVI. This requires that the calling application knows the names of the controls of the subVI for processing. Overall this is a reasonable work around but ultimately I am looking for a truly generic solution which decouples the top level VI from the called subVIs.

All I want to know is when the subVI exited. I don't want to know anything about the internals of the spawned VI nor do I want to require the spawned subVI from having to do anything special to inform the caller that it has exited. It would seem reasonable that the caller should be able to be informed of specific events of the spawned VI.

I do appreciate the suggestions though. And this callback solution could be useful for other tasks.

The example does, yes. Because you don't know what controls maybe on the front panel. But ALL vis have a generic on-close event So don't need to know anything about the sub VI. You just inspect the reference when the event comes in to find out which VI closed.

So the install callback just becomes:

Haven't been through it thoroughly and perhaps not as "clean" as you would like (I suspect you were expecting to just select it with 0 programming). But better than nothing eh?

Edited October 5, 2010 by ShaunR

[Mark Yedinak]

So far nothing is working. I have tried Shaun's approach but I am not seeing any events in my top level VI. I attached the simple example that I have been playing with.

Main.vi

PanelClose Event Callback.vi

Task.vit

[ShaunR]

So far nothing is working. I have tried Shaun's approach but I am not seeing any events in my top level VI. I attached the simple example that I have been playing with.

You are not generating an event.

I've had a play and it seems that the panel close event isn't really an "OnPanelClose". It is only an event generated by clicking the close button. That's not really what you are after. To also include a boolean you would have to attach to the on-value as well.....too much effort. Might as well put an event after the while loop.

Back to the drawing board

Perhaps the 'VI will be purged' event is something you want?

Ton

I never had a lot of luck with it (maybe because I don't fully understand it). But sometimes it worked, sometimes it didn't.

[Phillip Brooks]

Are you averse to any polling, or just polling in your top level (UI?).

Maybe define a 'monitor' task that is run at start and receives an event ref and notifier.

Pass your task VI instances via the notifier (or queue or functional global or carrier pigeon) to the 'monitor'. The monitor would periodically evaluate the array of task VI refs by checking the Execution.State property of each ref; generate an event for each vi that is not 'Run top level'.

I smell an Idea Exchange suggestion in this problem...

[Mark Yedinak]

Are you averse to any polling, or just polling in your top level (UI?).

Maybe define a 'monitor' task that is run at start and receives an event ref and notifier.

Pass your task VI instances via the notifier (or queue or functional global or carrier pigeon) to the 'monitor'. The monitor would periodically evaluate the array of task VI refs by checking the Execution.State property of each ref; generate an event for each vi that is not 'Run top level'.

I smell an Idea Exchange suggestion in this problem...

I have already posted the the idea in the Idea Exchange.

As for polling, I like to avoid whenever possible. I prefer to use events, queues or notifiers. However, your suggestion does sound like a reasonable work around until a true event is implemented. This would allow any subVI to be used without requiring any special code in it. Thanks for the suggestion.

[asbo]

... (or queue or functional global or carrier pigeon) ...

[Phillip Brooks]

RFC 1149 ( A Standard for the Transmission of IP Datagrams on Avian Carriers) had the idea 20 years ago, I just thought it was time we had a new way to pass data in LabVIEW...

[Dan DeFriese]

However, I was hoping that LabVIEW would already provide a general method to allow calling VIs the ability to catch when a VI it spawned closed. This seems to be something missing which would be very useful for managing spawned tasks.

The caller can use the method "FP.Close" to cause the called subVI to exit. However, the reverse it not supported since it appears without extra effort the top level VI is unable to detect when a subVI closes.

How would this event be more useful in managing spawned tasks? (As opposed to using and messaging primative queue, notifier, user event.) If the Dymamic Asynchronous VI (Daemon VI) is running in its own call stack and exits autonomously, wouldn't the VI Reference of that VI become invalid? If so, I'd suspect that the VI Ref terminal in the "VI Exit" case of event structure on the top-level (spawner) would be invalid and otherwise useless.

I don't mean to knock your idea. I'm just missing how this would be useful.

[asbo]

If the Dymamic Asynchronous VI (Daemon VI) is running in its own call stack and exits autonomously, wouldn't the VI Reference of that VI become invalid? If so, I'd suspect that the VI Ref terminal in the "VI Exit" case of event structure on the top-level (spawner) would be invalid and otherwise useless.

No, the reference wouldn't go invalid - LabVIEW would prevent the VI from unloading from memory -because- that reference is still open. I don't think that there's a way that a subVI could force itself to go out of memory in that scenario.

[Mark Yedinak]

How would this event be more useful in managing spawned tasks? (As opposed to using and messaging primative queue, notifier, user event.) If the Dymamic Asynchronous VI (Daemon VI) is running in its own call stack and exits autonomously, wouldn't the VI Reference of that VI become invalid? If so, I'd suspect that the VI Ref terminal in the "VI Exit" case of event structure on the top-level (spawner) would be invalid and otherwise useless.

I don't mean to knock your idea. I'm just missing how this would be useful.

In order to provide a more general solution I would like to see an automatic event generated when the subVI exits. By requiring the use of one of the messaging primitives the subVI is tied to this application. At bets, you must define a standard messaging architecture that will be shared in all of your applications. By decoupling the subVI from the messaging scheme via an automatic event you significantly increase the reusability of your code. You can easily use in int any application without requiring any code modification. The primitive messaging methods would most likely require modification of code. Even with a more generalized approach should you ever change the messaging structure all of the existing code that uses this scheme would have to be modified.

[Dan DeFriese]

At bets, you must define a standard messaging architecture that will be shared in all of your applications. By decoupling the subVI from the messaging scheme via an automatic event you significantly increase the reusability of your code.

Thanks for expaining.

Personally, I'd prefer a standard messaging architecture. When a VI exits unexpectedly (assuming this is what your trying to catch) I'd want to no why. That is, the error value on exit.

While I can see how a built in event would be easier, I'm not sure if it would be more useful than queues and notifiers to my typical usage.

~Dan

[ShaunR]

As I've said before. the Events in LV need an overhaul. There are lots of available events that we should be able to hook into. We have an event for when a VI is activated, why not when it exits, or is loaded, minimized, maximized etc?

[Mark Yedinak]

Thanks for expaining.

Personally, I'd prefer a standard messaging architecture. When a VI exits unexpectedly (assuming this is what your trying to catch) I'd want to no why. That is, the error value on exit.

While I can see how a built in event would be easier, I'm not sure if it would be more useful than queues and notifiers to my typical usage.

~Dan

It make things easier if you are working in an environment where you are building lots of different types of applications and you want/need a generalized approach for catching this type of event. By using a standardized messaging architecture (which will work) you are limited to being able to use subtasks that adhere to this architecture. You can't easily reuse code developed elsewhere. In addition, can see a system that will spawn subtasks which are effectively standalone applications which may be terminated by the user or the application itself in a normal fashion (no errors). The controlling application will want to know that the subtask has exited.

This is an area like Shaun has stated needs an overhaul. Being notified an application or tasks has exited is a reasonable thing to want to catch. Why should we have to roll our own solution? Shouldn't the language provide this as a core functionality?