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

[Michael Schnell]

  On 10/11/2010 01:15 PM, Michael Van Canneyt wrote:
>
>
> 1. Make sure you make something that can be integrated with the FPC 
> rtl/FCL.
This would supposedly be doable be based on MSE's code. But it would 
need to include quite a lot of MSE code lines, as the Event queue type 
is nicely structured and derived form more basic queue types that would 
need to be used.

it would not be really easy to test it as it does not synchronize with 
GUI events when used with Lazarus.

>
> 2. Once that is done and it is performing as expected, it should not 
> be hard
>    to convince the Lazarus people to use it.
I doubt that, as it would need to replace the basic event management in 
all Widget sets, They even two manage complete different KDE Widget Type 
code bases because they don't want to take the risk of breaking old code 
when having it use using common functions with the new KDE Widget Type. 
Moreover all other Widget Types (GNU, Mac, fpGUI) have their own 
implementation of an Event queue in Pascal code, and the Windows Widget 
Type uses the OS'es Message queue. Replacing all of them with the 
methods provided by the RTL would be necessary (and GUI events would 
need to be merged in the way all but Windows Widget Set code does)
>
> If of course you expect to achieve a total shift in paradigm, then 
> you'll be disappointed, because Delphi compatibility is paramount.
Of course Delphi code would need to run in the same way as it does at 
the moment, I don't think this is difficult to be achieved.
>
> I beg to differ. From my perspective, people bring up issues, you 
> bring up
> the event mechanism in one of the replies.
Only if I the event mechanism is the only I see how to solve the problem.
>
> At least, it would be a start. Now there is nothing, so we cannot even 
> verify that your mechanism is indeed a superior mechanism, as you claim.
In fact Lazarus does provide Windowistic Messages from a thread to the 
Main Thread as a basic event mechanism. I did test this some months ago 
and it did work fine. But it seems to be broken for Linux (KDE) with the 
current svn version. "My mechanism" is superior in that it would be 
usable without a GUI (that is why I did the work on that some months 
ago) and would be implemented in a centralized way independent of the 
GUI and thus the code should be better manageable.

Regarding functionality it _could_ be better: Windowish messages provide 
three free queued 32 Bit parameters to  the event handler procedure. An 
implementations like Delphi's "TThread.Queue" would provide no parameter 
(but self). A decent event queue _could_ be implemented like an an RPC 
scheduler and provide any number of marshalized queued parameters.
>
> While I agree that an object is a clean approach, for most purposes, 
> an object is simply unnecessary overhead, because it requires 
> additional heap storage.
A simple implementation for something like TThread.Queue would need to 
do a queue of recored with a pointer to the procedure and it's self 
pointer. A more advanced implementation would additionally need 
marshalized parameters. Maybe a sensible approach is doing a queue of 
three words: procedure pointer, self pointer and additional pointer. 
This would allow for (1) reproducing TThread Queue and (2) allow for 
parameters on the heap with the additional pointer pointing at same. If 
we want to reproduce the Windowish Message stuff (for Delphi 
compatibility) I suppose it would be good to use four Integers as queue 
records (avoiding the term Object).

-Michael