On 08.10.2010 18:13, José Mejuto wrote:
Hello FPC-Pascal,
Friday, October 8, 2010, 3:49:52 PM, you wrote:
GG> The application needs to wait for the logging threads to complete
GG> before it can terminate.
GG> This is where the problem comes in. As soon as I call
GG> SomeThread.WaitFor, the application is frozen - it never gets to
GG> terminate completely because WaitFor never returns. All our apps are
GG> database GUI apps, but strangely enough, it is not only limited to GUI
GG> apps. The unit testing framework of tiOPF is Text or GUI. I run the
GG> daily build under our Linux server and it is non-gui based. The test
GG> runs never complete/terminate because there are five logging threads
GG> frozen which never returned from WaitFor. So I had to implement that
GG> boolean field and a while loop hack, instead of calling WaitFor [when
GG> I use FPC and Linux].
Are you calling Synchronize inside the thread ? Synchronize will only
happend when Application.ProcessMessages is being internally called,
which not happend if you are WaitingFor. I think that if the thread
calls Synchronize while you are in the WaitFor you will be in a race
condition, Synchronize waiting for Application.ProcessMessage and the
application waiting for the thread to finish.
This isn't a race condition, but a dead lock (but both are bad things ^^).
Also on Windows this works, because on Windows WaitFor handles
Synchronize events as well.
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
