Synchronize () DLL freezes without errors and crashes

0
votes

I built a modular program consisting of several programs (exe), and in some cases these modules are also in DLL. There are about 6 modules.

All of these modules used functions of a Thread. This thread does not use visual components, what it does is basically analyze huge files (> 1GB).

To improve the efficiency and organization, extract all the code relating to this file analysis, which is used by each of the modules. This facilitates updating and find error.

The threads worked normally before, no code change, except as necessary to adapt them to the DLL project.

Now, when I run the procedures of Thread, everything functions normally except the synchronize () method, which freezes without making errors or lock the main program.

The synchronize () method is used because the threads are created entirely within the DLL. Therefore, the main program is called a procedure DLL, which creates and runs the thread, without any intervention by the main program.

For this procedure are passed several parameters, one of them is a type "pointer to procedure" ^procedure, who is using it as an event, fired by the thread through the synchronize () periodically, ensuring that during the performance, which lasted more than one hour in most sometimes, if track progress, see errors errors among others.

I searched on google but did not find information except someone saying that possibly the synchronize () method is waiting for the main process that is not responding for unknown reasons.

Note: The main program and the window does not lock or freeze; only the thread that does not call / run procedure provided to synchronize (); I confirmed it!

Added

Nota2: I want to avoid as much use PostMessage () or similar, because it forces me to include LCL, which makes the DLL file up from the current 300K to 2MB (in release mode). Apart from that there are reports that its operation is not good as expected.

1
multithreadingdllpascallazarussynchronize
The user who opened the question of this link found a solution (last answer), but does not work for me; even with little adaptation for FPC. - guinalz
Any such solutions are hacks, also on Delphi, and require advanced debugging skills to keep working. - Marco van de Voort
Provisionally, I created a unique DLL to call PostMessage () and sendmessage (). This is not the best solution for me, and is far from the solution I want. But there are several DLLs prevents including the same functionality, each with oversize duplicate data; only to implement a detalhinho, such as sending message. In other words, I now have only one DLL with this waste of bytes available to all others. In my thoughts, TThread.sincronize () has to work; this is its function, and failure indicates to me an obvious construction flaw in Pascal / Lazarus. - guinalz
Yes. FPC does not deliver a runtime in DLL form, partially because the many (not all COM like VB) automated type make a simple approach futile. The good solution already pioneered by Delphi is packages and that is already in the works in trunk, as you would have known if you had bothered to read the link in my answer. - Marco van de Voort
I read the link, and I had read before opening this issue! As I understand it, it is even that Lazarus does not implement dynamic packages yet, just Delphi. Ie, it does not solve my problem! I did not buy Delphi. Correct me if I'm wrong, but to install the package to Lazarus, he will be compiled and included within the EXE, correct? If so, I do not want! I want an external library, shareable and replaceable! This idea is the great advantage of having a dll. Because if I wanted to, in the end, compile everything into an EXE there is no need to ask this question, and package becomes useless. - guinalz

1 Answers

0
votes

That is because you have two complete instances of everything (RTL,LCL etc). One set in the DLL, one set in the EXE. Both code and data.

You are probably calling the synchronize of the DLL, which schedules it for the LCL loop in the DLL which does nothing, since all work is done in the EXE.

This will be very hard to fix, basically you need packages for this. Partially also because the thread involvement will further complicate it because of threadvariables (Thread local storage) that is set up potentially differently for DLL and EXE threads.

For this one needs packages which is only in its initial stages and solves this by having only one copy of everything. See the link for a deeper treatise.