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

[Michael Van Canneyt]

On Mon, 11 Oct 2010, Michael Schnell wrote:

> On 10/08/2010 05:44 PM, Reimar Grabowski wrote:
>> As I said, threading is an "advanced" feature, and clearly here are
>> many developers that are afraid of something they don't understand, so
>> simply think banning the feature is the solution.
> In fact IMHO "Object Oriented" "Event Driven" programming such as provided by 
> Delphi/FPC is all about avoiding the complexity of threads and still being 
> able to handle asynchronous events (such as GUI events) by having the RTL 
> transform ()and the OS  them into "run-to-completion" Language-Events by 
> means of queuing them  in an event queue.
>
> Of course the leads to restriction with latency and (when running on a 
> multi-Core system) performance.
>> Simply learn
>> multi-threading, get some experience with it, then using threads are
>> not a problem. It's the same deal as using Pointers. IF YOU DON'T KNOW
>> WHAT YOU ARE DOING, YOU ARE F**KED.
> Yep ! The language and RTL should decently support threading for those that 
> need it and are willing to deal with the implications and complexity. This 
> includes providing means to notify the main thread from worker threads as 
> well in a synchronous way (such a s TThread.Synchronize) as in an 
> asynchronous way (such as TThread.Queue or (better) "procedure...message" ore 
> (even better) a decent  event queue such as provided by MSE. This of course 
> automatically includes TThread.Waitfor.
>
> Of course in this event queue GUI events need to be  automatically merged in 
> case a GUI Widget-Type is used.

It would be good if you could provide a patch, instead of continuously
restating your desire of this feature. 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 ?

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. You can change this by providing a patch. It does not need to
be perfect, but it should provide a working - cross-platform - start of an 
implementation. Then we can see where we can fit it in. You can start by
creating an descendent of TCustomApplication or so: TCustomEventApplication.

Michael.