Using Synchronize in a DLL

Forum > Other

(1/1)

calvarez:
I written an application that loads a DLL. The application also takes care of calling an exported function from the DLL to create and start a thread in the DLL. When the thread is running, it will be listening to packets that arrives at the servicing port. I encountered a problem if I wrapped my calls within the Execute(...) function with Synchronize(...). The application in fact, hang at the first wrapped Synchronize(...) call. However, if I take the wrapper out, the
application seems to be running fine. Previously, before I split my application into a DLL and a caller application, the use of Synchronize(...) posed no problems. But when I use
Synchronize(...) in a DLL, there are problems mentioned above. Thanks and kind regards.

marcov:
The trouble is that you have two sets of state related to synchronizing, since both the mainprogram and the DLL have a complete copy of the RTL state. (all variables)

To transparently divide a program in to multiple modules (mainprogram and DLLs) you need packages.

A workaround would be to somehow call the tthread.synchronize in the main program (e.g. by callback or so) so that all synchronization is done with only the mainprogram state.

eny:

--- Quote from: marcov on April 12, 2014, 11:21:09 am ---To transparently divide a program in to multiple modules (mainprogram and DLLs) you need packages.
--- End quote ---
You mean this url :)

CCRDude:
Been there, more than once :) And am back to the topic this week, looking for other workarounds.

Background:

* Code using threads in a git submodule often used
* Changing the use to Lazarus packages instead
* Previously, was using TDLLCompatibleThread that $IFDEF DLLThread used critical sections instead of Synchronize.
* With packages, $IFDEF no longer seems to be an option
* IsLibrary is said to be unreliable as well (system.inc seems to indicate this is true for packages).
* Callback for Synchronize will not do because existing DLLs and other language hosts do not use it.
* I also use this code in command line tools, some with TCustomApplication, some without.
In this situation, my ideas are:

* Getting the current modules filename and checking extension for .dll (.so &c) might do, but fails on renamed file extensions,
* is there a better FreePascal or, if not, operating system call to check if the currently running code is within a library?
* Sounds like an ugly dependency, but Application.MainForm not being assigned might speak for the code to run from a DLL?
* if (not Assigned(Application)) or (not (AppInitialized in Application.Flags)) could also indicate that thread synchronization is not available?
* generally, looking for a way to detect if the synchronize mechanism is available would be better than just guessing by the file type of course

Navigation

[0] Message Index