[fpc-devel] Threads and alot of crap continued
JeLlyFish.software at gmx.net
Wed Nov 8 08:35:21 CET 2006
On Tuesday 07 November 2006 16:10, Ales Katona wrote:
> As for general use, you can't do a Timer this way.
Believe me, I can. :)
> You can't just put
> a TTimer in which works in it's own thread and then calls some
> callback in it's own thread,
I even call the callback of another thread. :P
> unless the users are informed, and-or
> the thing is locked and protected but you can't do that from within a
> TThread (because you don't know what the callback code is).
Well, in Turbo Pascal I could write interrupt handlers the wrong way,
without locking code/data in question and nobody cared about that
But if that's so complex: Why don't you use the usual synchronization
stuff then to put the asynchronous timer event in a message queue using
> In case of gui TTimer this cannot happen because it's not threaded,
> so the userloop would first finish, then the user function returns
> and the main gui loop does it's stuff (this is my oh-so-complicated
> part, done by the gui).
The problem in a portable general solution is that the may be no "main
gui loop" and you can't just write one and force anyone to use it,
So why don't you use Synchronized/CheckSynchronize (or whatever it's
If you'd do that, the timer event callbacks would be queued and then
executed in the context of the main thread.
The user is only required to call CheckSynchronized from time to time,
but because the accuracy of the time of execution of any associated
handler is in the hands of the user anyway as long as you stick to a
synchronous solution to avoid putting the burden of locking data to the
As long as you don't want to implement real-time behaviour, I don't even
see a problem in that. If the user decides to not call/execute any
provided "message event loop", the execution of the timer handler code
will be deferred until the end of the universe anyway.
More information about the fpc-devel