Hi All:

I am still trying to get timers to work in a console mode program. While I was doing that I ran into problems with TThread.

Question: Do console mode programs have a "run loop"?. The reason I am asking is that both Raspbian and Linux Mint TThread's Synchronize method apparently does nothing (it works fine when used with LCL). I can call it, but it doesn't run the method passed as a parameter, nor does it return.

I wrote a trivial console mode program that uses TThread and tested it on both Raspbian and Linux Mint with exactly the same results.

The simplest Execute method fails:

procedure TXThread.Execute;
begin
   Synchronize( Callback );
end;

I have tried stepping into Synchronize, but even the debugger seems to get lost.

If I change Execute to:

procedure TXThread.Execute;
begin
   Callback;
end;

the Callback method is invoked (seemingly in the main thread, but I'm not sure... Will have to figure it out later).

Thanks,

Don Ziesig

[...] Question: Do console mode programs have a "run loop"?.

Synchronize requires that your main thread calls CheckSynchronize from time to time. The LCL does that in its loop.

[...]

Mattias

That made it work! Thank you. (Where is this documented?)

Don

In CheckSynchronize itself, but not in the wiki multithread tutorial. I added it there.

Mattias

Cool! Thanks again.

Now back to TFPTimer. I got it working with a hack in TFPTimerThread.Execute:

As implemented it calls Synchronize(@T.Timer). This does *not* work. In desperation I hacked it to call Queue(@T.Timer) and it works perfectly. I understand the difference between Synchronize and Queue, but I sure don't know why Queue works and Synchronize doesn't in this case. (Only on the PI, I didn't try this on Linux Mint).

Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160721/75e2be57/attachment.html>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160722/a2743994/attachment.html>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160722/dac49d13/attachment.html>