[fpc-devel] Threads and alot of crap continued

[Vinzent Hoefler]

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 
simple fact.

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 
Synchronized?

> 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, 
right?

So why don't you use Synchronized/CheckSynchronize (or whatever it's 
called) then?

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 
programmer.
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.


Vinzent.