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

[Adem]

  On 2010-10-12 11:47, Michael Schnell wrote:
>  On 10/11/2010 11:34 PM, Adem wrote:
>>
>> Plus, even if it is a paradigm shift, it does not sound as if it will 
>> immediately bring the whole house down.
> That is right, but it would need more than a one person team. 
These things usually do.

But, you seem to have made some headway and that appears to a good point 
to start from/with.
> It of course would need a new svn branch as well in FPC as in Lazarus. 
> So the appropriate experts would need to help. I did (most of) an 
> implementation using code taken from MSE (I consider the quality of 
> this code extremely high and Martin was very helpful when I worked on 
> his code. He even refactured his code base to avoid the name "Event" 
> that was used in a different definition as it is in Lazarus.)
Can't sepak on behalf of anyone but I doubt you will be denied a brach 
--taht's what I gatehered from Vincent's  words ["no 'political power' 
needed."]
>> Once it gets incorporated into FPC and proves to be a superior 
>> solution, GUIs can adopt (or adapt for) it in their strides.
> What do you think should be considered superior.
What you've listed below --plus that a solution will be available for 
non-Lazarus and in Lazarus-non-GUI applications.
> This is what I think would be improved;
>
>  - an Event Queue would be available in non-Lazarus and in 
> Lazarus-non-GUI applications (so even MSE could benefit from moving 
> part of it's code into the FPC RTL)
Good.
>
>  - additional to the current LCL event mechanism "SendMessage" / 
> "Procedure ... Message" (which would be implemented on top of the new 
> one) we would have an RTL based "FireEvent" / "Application.Event" 
> mechanism that not only fires "Windowish" Events with three 32 Bit 
> Parameters but Event handlers with multiple marshalized/queued 
> parameters. A "Procedure...Event" syntax candy could be done on top of 
> that.
Good.
>
>  - The implementation could be done in a thread save way so that an 
> Application object could be instantiated by a worker thread and so 
> same gets its own event queue allowing for inter-thread notification 
> and RTL-based TTimers, thus allowing for a decent event-driven 
> programming paradigm in all threads
Good.
>
>  - the "Event-Queue" code is centralized in the RTL and not 
> reduplicated in any Widget Type, improving manageability and thus 
> helping enhancing and debugging it (see: currently broken 
> implementation for Synchronize and SendMessage in Linux, not yet 
> existing Delphi-compatible  TThread.Queue)
Good.
>
>  - this could be the base of thread-pool driven implementation of 
> Prism-compatible parallel loops / future variables by means of the RTL 
> and appropriate syntax candy. (Other ways of providing parallel 
> execution can be considered as well)
Good.
> What will not be improved:
>
>  - performance (it supposedly will not be degraded, either), unless we 
> in fact think about parallel loops or other ways of parallelizing)
So, no loss/damage there.
>   - current projects and "Delphi"-code will not benefit (but it of 
> course will not need any modification)
That's good enough for me. If anyone wants to use this new code, s/he 
would have to add the necessary glue code using IFDEFs, right? If so, I 
can't see any damage there either.
> I don't have much hope that the maintainers of the different Widget 
> Type implementations agree that this is a viable improvement.
My hope/guess is that they may want to modify/extend it in time to cover 
their specialized needs (if any); but, having a universal/common code 
should benefit them/everybody too.

All in good time.

Cheers,

Adem