View Full Version : hold off Girder while plugin completes action

October 13th, 2002, 03:55 PM
The best thing in the current framework would be to NOT return the clean_up_device
until the device actually finished _ALL_ its
threads. this is not only the best thing but this HAS to be the case because the code gets unloaded right after you exit from the clean_up device thus if a thread is still running the code will be ripped out from under its foundation.

Mark F
October 13th, 2002, 03:55 PM
Sorry, I don't have a good answer for you. :sad:

If you have to complete an action of some sort (pulsing a data line), there isn't much that you can do (in a single process model) but hold off the plugin unload until you have completed the action.

An alternate approach would be a multi-process (client/server) model. When your plugin loads, have it spawn and "attach to" a new process that accepts commands and executes those commands. Each action would have the plugin post another command to the server process. On unloading of the plugin, it could post an "exit" command to the server process which would cause it to exit when it reaches that command.

I hope this helps.

October 13th, 2002, 03:55 PM
I'm still developing the Q14 plugin and have
a problem: when closing Girder it is possible
to execute an action like pulse an output
line for xxxx milliseconds. The pulsing is accomplished by a timer in the DLL itself and works just fine, but.

If Girder closes down it has to wait for the action to complete, I tried creating an event object and waiting for it to become signaled (but then everything freezes), or create a new thread when the plugin is loaded, but then Girder blocks immediately.

Does anyone have a sample or can somebody help me out pls?!

October 13th, 2002, 03:55 PM
I found a solution by taking over some code from the Parallel port plugin sample.

Probably one of my previous solutions worked too, but it was placed in the DllMain(DLL_PROCESS_ATTACH) call which seems to be too early.

Now I've put it in the setsupportex and close_dll calls and it's fine (have to verify it with the actual HW this evening, but I see a delay when closing Girder, as expected).