[fpc-devel] Threads and alot of crap continued

[Vinzent Hoefler]

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 
something wrong?

> and if you go single-threaded you have to provide the main loop
> hooks).

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;
> begin
>   Timer.Timeout:=somenumber;
>   Timer.OnTimer:=@somecallback;
>   EventHandler.RegisterTimer(Timer); // could be the other way around
> end;
>
> procedure MainLoop;
> begin
>   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;
>
> begin
>   Init;
>   MainLoop;
> 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.


Vinzent.