[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 11:39 AM, Michael Van Canneyt wrote:
>> 
>> 
>> It would be good if you could provide a patch, instead of continuously
>> restating your desire of this feature. 
> I'm not stating my desire of this (set of) features). I'm just confirming 
> that others stating this desire are not alone.
>
> At the moment I am not actively working with Lazarus at all (just evaluating 
> chances for future projects). So actively working on improving it would just 
> be a charity project and unfortunately I don't have the time for this right 
> now. (both facts can change any day in the future)
>
> In fact, some months ago (when I had more spare time) I did invest some two 
> weeks of work on implementing MSE's event queue mechanism in Lazarus, but I 
> found the correct way to implement this would be to do it in the FPC RTL (to 
> allow for an event queue independent of the GUI) and to modify the Lazarus 
> LCL to implement it's event queue based on this (merging the GUI events 
> similar to how it right now it's done in all Widget Types but "Windows"). But 
> i feel providing interdepending patches for both FPC and Lazarus is fay 
> beyond my political power.

There is no 'political power' needed.

1. Make sure you make something that can be integrated with the FPC rtl/FCL.

2. Once that is done and it is performing as expected, it should not be hard
    to convince the Lazarus people to use it.

If of course you expect to achieve a total shift in paradigm, then 
you'll be disappointed, because Delphi compatibility is paramount.

>> You manage to bring it up quite
>> often. That means you think about it often, so why not try an 
>> implementation
>> while you're at it ?
> In fact I did (see above). There are some discussions on the here in the back 
> log and in the MSE discussion group.
>> 
>> If it wasn't implemented till now, it's because none of the core developers 
>> sees the need for it, and by the looks of it, this will not change in the
>> near future. 
> In fact 90 % of the discussion threads here (and in some more groups) brining 
> up this topic have not been started by myself. So I feel that there seems to 
> be a decent "public" request.

I beg to differ. From my perspective, people bring up issues, you bring up
the event mechanism in one of the replies.

>> Then we can see where we can fit it in. You can start by
>> creating an descendent of TCustomApplication or so: 
>> TCustomEventApplication.
>> 
> Thanks for remembering my dream of providing an event queue even for worker 
> Threads :) AFAIK, MSE in fact can do this. As I did not see any need (but 
> that of my brain wanting perfect structuring) on that, this would be just a 
> nice add-on, that supposedly would not need much additional effort by doing a 
> thread-save implementation of TCustomEventApplication. :).

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.

>
> But here again, the FPC implementation is involved as "Procedure ... Message" 
> would need to be implemented ion top of the event queue and in fact the 
> Windowism of the Message type should be dropped in favor of a decent Object 
> based Event Type (such as provided by MSE).

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.

Michael.