On 07/22/2016 03:42 AM, Michael Schnell wrote:
On 07/21/2016 11:37 PM, Donald Ziesig wrote:
TThread.Queue simply schedules an event in the Main Thread queue (i.e.
an event handler procedure will be called when the main thread next
time calls CheckSynchronize() ) .
TThread.Synchronize additionally stalls the thread that calls
TThread.Synchronize() until the main thread is done with executing the
scheduled event handler procedure.
-Michael
Hi Michael,
I know the difference between Synchronize and Queue.
The problem is that Synchronize appears to suspend the main thread (but
only when used in TFPTimer). I have test programs that show that
TThread.Synchronize properly suspends the calling thread and executes
the callback using the main thread when TThread is used by itself.
On the other hand, when TThread is subclassed to be the TFPTimerThread,
Synchronize appears to suspend the main thread and the program hangs.
The thread ids are all appropriate (Synchronize is called from the timer
thread) but, once called, Synchronize never returns and the callback is
not executed. When Synchronize is replaced by Queue, the timer program
works as expected (the timer thread continues execution immediately
after Queue returns, instead of waiting for the callback routine to finish).
Both cases behave identically on the Raspberry Pi and Linux Mint so I
believe that the problem lies in the FPC code, not the OS.
This does not make any sense to me, but, since the behavior of TFPTimer
(as modified to use Queue) is appropriate for my application, and I do
have a deadline, I will use the modified TFPTimer and return to this
weirdness when my project is done.
Thanks,
Don
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus-ide.org/listinfo/lazarus
