[Lazarus] TThread.WaitFor blocks the main event loop under Linux

[Michael Schnell]

  On 10/18/2010 09:57 AM, Michael Van Canneyt wrote:
>
> How else can you do this ? Each widget system uses it's own 
> mechanisms, the LCL must somehow unify this, and they did. To remain 
> delphi compatible, they based the 'public interface' on the Windows 
> mechanism. 
"Windows" is the only OS that provides an Event "Message" queue to the 
running applications (in fact Windows even does provide it to any 
thread, while Delphi and Lazarus only provide means to use it in the 
Main Thread). With all other "Widget Types" (that allow for Event Driven 
programming) the Event queue is done in pascal code in the LCL (or MSE 
library). All these Widget Types are binding to a GUI Tool set that uses 
call backs to fire the GUI events. Theses GUI events need to be 
scheduled together with Timers and thread based events, so an Event 
Queue is implemented in Pascal code.

A decently versatile central Event Queue implementation (best: in the 
RTL) would be usable for all Widget Types. With Windows it needs to be 
checked if this leads to a performance degradation (using user space 
code instead of doing some additional system calls might in fact even 
improve the performance, but with all other Widget types the resulting 
code flow should be quite similar and thus performance should stay the same.

> There was no
> point in adding an additional layer in between.
I explained several points that could be improved by this in the mail 
above to which Adem replied with the multiple "good"s :) .
>
> That they succeeded in doing so is quite an achievement.
Yep. I am very happy that there have been all these knowledgeable and 
helpful people that made th current implementation work !
But the forking of the Event Queue code of course is a result of 
historical reasons and not of a previous plan. I am sure if the same 
people had been in a position to do a plan for the current extent of the 
LCL before starting the first line of code they would decide to do a 
central Event Queue implementation.
>
> Martin doesn't care about Delphi compatibility. 
This is true, but IMHO it's not really relevant. The makeup of the 
message queue does not harm nor force Delphi compatibility. A decent 
Event Queue can schedule Windows-Compatible GUI events and 
Delphi-compatible "Procedure... Message" (e.g. by emulating Windows 
Messages), schedule parameter-less Events (for Delphi compatible 
"Synchronize" and "TThread Queue". Additionally it can schedule any 
"advanced" GUI events another Widget Type might ask for.
> This is his decision, and
> allows him more freedom in his choice of event system, and he has 
> maximised
> the options he had. 
In fact I did a deep look at his Event Queue implementation when I 
ported it to Lazarus/Linux. I did not see anything that would prevent 
Delphi compatibility but the use of the identifier name "TEvent". Upon 
my request, Martin already changed this name in is snv, so that I could 
do the porting just by copying unmodified snippets of his (then) current 
svn code, as was my intention.
> You are free to prefer his code over the LCL. Open source is about 
> having the choice.
Yep, if I would prefer his complete system (which I don't for obvious 
reasons as stated above) I would just use it, but do not wish for an 
additional ninth implementation of the event Queue mechanism for a 
non-GUI Widget Type (that was my original intention) forking whatever 
code available.

This would increase the said Open Source nightmare that currently 
prevents doing a (IMHO viable) improvement.

-Michael