Timeout for Call library Function

[Andrey_Dmitriev]

In some cases we may have functions called from DLLs, which cannot be not terminated in "normal" way due to some reasons.

When source code for DLL is available, then this is not a problem, but for third-party DLLs this may be terrible.

All what we needed is Timeout for External Code Call.

Let me explain. For example, we have code like this:

when such external code called from VI, then this VI cannot be stopped

Suggestion:

add Timeout option to the following dialog:

When enabled, then the following input will be shown:

And timeout can be programmatically defined on the block-diagram:

by default -1, of course.

I fully understand, this is dangerous thing, but in some cases we needed this. Suggested is something like TerminateThread function.

Back to the code above, when this code should be terminated, then we needed wrapper something like this:

Then this function can be called in separate thread:

And now we can terminate execution with TerminateThread function:

Then in LabVIEW it looks something like this:

Now we can "Abort" our infinite DLL call without any dialogs like "Resetting VI", etc.

Again, this is dangerous feature (but not more dangerous as TerminateThread itself), and may be is necessary in the most extreme cases, otherwise the only way to stop the application is taskkill.

[AristosQueue (NI)]

One cannot simply terminate a thread -- that DLL may be manipulating any number of data structures that were passed into it. If you say, "well, then we'll restrict the types that can be passed into the DLL only to types that are passed by value and have no hair" then you've ruled out a vast set of DLL calls -- no strings, no arrays. Even if you make it safe as far as sharing the data structures back to LabVIEW, you still leak memory all over the place. The only way we could terminate a DLL call is by running it as a separate *process*, which would involve a lot of data marshaling.

You are asking for a general feature of LabVIEW to solve a problem that is not generally solvable. Terminating your particular DLL call may be relatively safe, but there is absolutely no way to explain to a person which DLL calls can be terminated and which cannot.

Instead of doing anything to LabVIEW, you should write a wrapper DLL for your particular DLL call, one that can do the thread-termination-on-timeout internally. This is not something LabVIEW should ever try to do. Yes, that means restarting LabVIEW if your DLL hangs. That is the price to be paid for having our dev and execute environments in the same process, something that has pros and cons. The pros historically outweigh the cons, and this is one of the cons. It is to be lived with, not solved.

[rolfk]

Actually, the entries in the Callback tab of the Call Library Node are exactly what would need to be assigned with functions very similar to what is suggested in this idea to implement that. So it is already there.

Yes it requires specific functions to be callable from the same (or a helper) DLL, which correspond to the required calling interface, but as mentioned already by AQ, that is not something NI could do out of the box for you, every DLL has its own particularities about how, if at all it could be aborted. Usually there are other ways such as Windows overlapped access that would be required to use for such an asynchronous checking and that can either be done from such "Callback" wrappers or by actually interfacing to the overlapped functionality directly through the Call Library Node.