[fpc-pascal] TThread.Queue vs TThread.Synchronize
Michael Schnell
mschnell at lumino.de
Mon Feb 23 12:25:50 CET 2015
On 02/23/2015 11:08 AM, Graeme Geldenhuys wrote:
>
> I've look at FPC trunk and see we now have a Queue() implementation, and
> I adjusted a simple multi-threaded GUI example app I had. But I still
> don't really understand what is the benefit of Queue vs Synchronise. I
> still had to create a "synchronise method" which I pass in to Queue() -
> similar to what I did for Synchronize().
I once did a testing program that checks the functionality of
TThread.Synchronize, TThread.Queue and Application.QueueAsyncCall (and
some other stuff) with and without attaching a GUI. Let me know if you
want to have it.
>
> Also how is Queue() calls processed? For example to get Synchronize() to
> work I had to call CheckSynchronize in my main event loop. Is this also
> required for Queue() functionality?
In the FPC RTL, "CheckSynchronize" in fact polls the Event Queue, and
performs the callbacks of the Events (Queued elements) that are push
upon this queue e.g. by TThread.Synchronize and TThread.Queue.
IMHO the legacy name "CheckSynchronize" is rather misleading.
Due to the "private" nature of the queue mechanism in the FPC RTL,
Application.QueueAsyncCall in the RTL works completely different than
TThread.Queue, (using a different Event (aka "message") queue that is
unknown to the fpc RTL but implemented (or attached to) by the LCL.
I once did a "non-GUI TApplication" for the LCL that does not attach to
any external GUI. It can't be "officially" released right now, as
Application.QueueAsyncCall needs to push events in the said queue. This
can't be done "directly", as the stuff is private in the RTL, and hence
I need to wait until the next version of the RTL provides TThread.Queue
that is usable for this purpose.
I once wrote a documentation on how the event queue in the fpc RTL
works, but failed with the attempt to have it included in the fpc help.
-Michael
More information about the fpc-pascal
mailing list