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

[Michael Van Canneyt]

On Mon, 11 Oct 2010, Michael Schnell wrote:

> 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.

I thought the one of the points was to have a message queue also when there 
is no GUI ? This should be testable, no ?

>> 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)

That's what I meant with a paradigm shift.

>> 
>> 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.

In that case, you see this quite often. Or, maybe more accurate, more than I
would.

>> 
>> 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).

Since integer is 32-bit, and you'd need 64-bit for pointers, you'll need to
test what size windows messages have.

Once more: please provide a patch.

Michael.