[fpc-pascal] TThread.Queue vs TThread.Synchronize

[Michael Schnell]

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