Using Synchronize in a DLL

[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]

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

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