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

Michael Schnell mschnell at lumino.de
Tue Oct 12 10:47:48 CEST 2010


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



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)

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

  - 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

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

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



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)

  - current projects and "Delphi"-code will not benefit (but it of 
course will not need any modification)



I don't have much hope that the maintainers of the different Widget Type 
implementations agree that this is a viable improvement.

-Michael




More information about the Lazarus mailing list