[fpc-devel] Threads and alot of crap continued
JeLlyFish.software at gmx.net
Tue Nov 7 14:57:15 CET 2006
On Tuesday 07 November 2006 12:42, Ales Katona wrote:
> If you want a "Timer" a "polling" mechanism has to take place which
> looks if something happened on some timer for example,
Is that so?
> OnTimer is "ready to be fired" (you can't call callbacks in threads,
I can't call callbacks in threads? Why's that? Or am I understanding
> and if you go single-threaded you have to provide the main loop
Do I? I always thought a timer is more comparable to an interrupt or
signal than a polling loop.
> So basicly, let's say TTimer is in RTL and there's some event
> mechanism already too, you'd have to do something like this:
> procedure init;
> EventHandler.RegisterTimer(Timer); // could be the other way around
> procedure MainLoop;
> EventHandler.HandleEvents; // if eventhandler after polling all
> timers in it's watchlist find out some has it's interval done, it
> fires it's callback end;
Timer.OnTimer := @Some_Callback;
Timer.Timeout := Some_Number;
Timer.Periodic := True;
And somewhere a "Timer.Start;", that should be it. There's no need to
register the timer in a global event loop or even explicitely calling
it. If that's needed on a particalur target, the timer's implementation
should take care of this.
> Apart from asynchronous stuff like watching handles etc. I don't see
> much use for this relativly complicated program model.
Don't know what's complicated here. It's asynchronous by definition, of
course, but apart from that?
Well, for me it would have saved me some time which I wasted in creating
threads that implement "timing events" by simply sleeping for a
particular time. And there's really nothing complicated in queuing log
messages and saving the queued messages every five seconds.
More information about the fpc-devel