How to response polling event during dll call

[George Lee]

Hello,
There is a long time dll call in my program. The program doesn't response to mouse click in the front panel during the dll call when I want to display other page in Tab control. It only response after the call.
How to solve the problem?
Thanks!

[Ben]

Wether or not it is possible to fix this situation is dependent on the dll itself.

IF
the dll is written to be re-entrant (thread-safe)
THEN
you can configure the Call Library function to not run in the user interface thread. This can be done by right-clicking on the node and selecting "configure". In the configure screen, ther is a drop down selection box that defaults to "Run in UI thread". Change this to re-entrant.

You can then determine which thread the dll runs in by setting the properties of the calling VI.

Warning!
If the dll is not re-entrant you WILL experience random crashes and possible data coruption! All bets are of if the dll is used in the wrong manner.

What is happening:
LV's execution systems are multi-thread with the exception
of the UI thread. The UI thread is single threaded to ensure updates of control and indicator information is updated correctly, etc. This thread also uses co-operative multi-tasking wherein a proccess is expected to "put itself to sleep" regularly in order to allow other proccesses in that thread to gain access to the CPU. Your dll is dominating this thread and prevent user actions to be serviced!

Final note;
If you do not know if the dll is thread-safe and decide you just want to experiment,

BACKUP YOUR ENTIRE MACHINE!

Ben

[Greg_McKaskle2]

> There is a long time dll call in my program. The program doesn't
> response to mouse click in the front panel during the dll call when I
> want to display other page in Tab control. It only response after the
> call.
> How to solve the problem?

To add to Ben's reply. Marking a DLL node as reentrant is safe if---

There is only one call to it anywhere in your program, and that call is
not in a reentrant VI.

It is safe if the DLL doesn't use thread local storage and make
assumptions about which threads will call it.

It is safe if the DLL protects its static data and can tollerate
multiple simultaneous calls.

On upgrade, and by default LV assumes that the DLL is not thread-safe,
as the result if the DLL is not thread safe is unpredictable and very

difficult to debug by conventional means. They tend to crash in many
different ways and othertimes simply produce the wrong results with not
crash. Frequently one of the above items is true. For the second and
third item, refer to the documentation or contact the author. You can
determine the first item yourself, and item number two is quite rare.

Greg McKaskle

[George Lee]

Hello Ben and Greg,
Thank you for your Help!
Follow your instruction, It can responses quickly during the Tab page click. Only the Abort button still need time to response after the dll call.

[Ben]

No problem George!

Ben

[Ben]

Hi Greg,

I would like a little clarification please.

First clarification:
You said

"
There is only one call to it anywhere in your program, and that call is
not in a reentrant VI.


It is safe if the DLL doesn't use thread local storage and make
assumptions about which threads will call it.


It is safe if the DLL protects its static data and can tollerate
multiple simultaneous calls.
"

and then made reference to them as 1,2, ans 3.

If the dll in question can run in any of the execution systems, then would "1" alone prove sufficient for proper operation?

The other requirements you mentioned should not be an issue if we can ensure there would be only one call at any one time as would be the case with the conditions of "1".


Second clarification:
You said "On upgrade". Des this apply to LV upgrades, ie LV 6.1.1 > LV 7, the dll changes or both?

Thanks,

Ben

[Greg_McKaskle2]

>
> If the dll in question can run in any of the execution systems, then
> would "1" alone prove sufficient for proper operation?
>
> The other requirements you mentioned should not be an issue if we can
> ensure there would be only one call at any one time as would be the
> case with the conditions of "1".
>
> Second clarification:
> You said "On upgrade". Des this apply to LV upgrades, ie LV 6.1.1 > LV
> 7, the dll changes or both?

Those answers weren't as clear as I would have liked.

There are really two requirements. #1 and #3 are two ways of
guaranteeing that the critical sections of the DLL have only one thread
in them at a time. #1 says that only one thread is there because your
LV logic only calls it in one place or only once
a time. #3 says that
only one thread is there because the DLL adds protection to guarantee that.

The second requirement is #2. LV has multiple threads. A given DLL
running in an execution system may be called each time with a different
thread. Any DLL assuming that it can store things in the DLL will be
pretty surprised and confused.

Fortunately, #2 is pretty uncommon, though certain database libraries,
and once upon a time even NI SW for instrument drivers made these
assumptions and stored thing in the threads.

So really, #3 is something that the DLL writer can make true, and #1 is
something you can guarantee.

Greg McKaskle

[George Lee]

Hello,
To be perfect, if there is a way to abort the dll call right away for stopping the software with the abort button? Or more, can I abort it with an own stop button in the front panel?
Thanks!

[Greg_McKaskle2]

> To be perfect, if there is a way to abort the dll call right away for
> stopping the software with the abort button? Or more, can I abort it
> with an own stop button in the front panel?

If the DLL has a way of notifying it to abort, yet. Most DLLs don't,
and that means that LV can either wait until they are done, or kill the
thread that is executing in them. Killing threads in the LV process is
possible, but it is a very good way to leave devices in bad states,
leave drivers confused, and leak major amounts of memory and
connections. If LV spawned, not just threads, but an entire process,
then it would be a bit more reasonable to kill the process, but that
isn't how things work today.

Greg McKaskle

[George Lee]

Hi Greg,
Thanks! I'll let the software wait the dll call done as your suggestion.