[Lazarus] Threads in Lazarus code base

Michael Schnell mschnell at lumino.de
Thu Sep 16 11:12:45 CEST 2010

  On 09/15/2010 05:25 PM, Michael Schnell wrote:
> That is why I vote for a message queue for the threads (implemented in 
> the RTL).

Just for the record:

I once tested (using Delphi) creating another TApplication instance in a 
TThread and without any problems I got a thread that not only does have 
it's own message queue but even a completely independent "Main Form".

Doing this in a decent platform independent way might require some work 
in the infrastructure, but I feel an improved way to handle this would be

  - The RTL provides a system independent message queue implementation 
in native Pascal code (could easily be "stolen" from the LCL's KDE 
Widget Type code).

  - for the main thread, the basic TApplication either uses this (KDE 
and most other Widget types) or replaces it by the OS'es message queue 
(Windows). Of course with this a decent "NoGUI" Widget Type is possible 
that implements a process-internal message queue without any GUI binding 
that allows for threads to notify the main thread, allows for TTimer and 
similar event sources to be handled in the normal "Delphi" way in a 
no-GUI application.

  - For a TThread, the user can select (by a property of TThread or by 
different TThread-alike types) if he wants either of
    - a traditional TThread "worker Thread" implementation without a 
message queue
    - an "advanced worker thread" that has a message queue but no GUI 
binding (allowing to receive normal events form other threads and e.g. 
from TTimers)
    - a thread that provides a TApplication instance and thus another 
independent "Main form"

Unfortunately while I suppose the software for this is not very hard to 
do (for someone knowledgeable with the Lazarus Widget Set 
implementations), to make this happen the Lazarus and FPC team would 
need to do a common synchronized update. I don't know if this is possible.


More information about the Lazarus mailing list