[fpc-devel] Threads and alot of crap continued

Vinzent Hoefler JeLlyFish.software at gmx.net
Wed Nov 8 13:28:28 CET 2006

On Wednesday 08 November 2006 10:53, Micha Nelissen wrote:

Sorry for all the confusion, I'm trying to clarify what I actually mean 
(or what I would *expect* from such a timer object):

> I don't see how async timers can be useful for software (maybe to
> control hardware perhaps, but only the trivial kind as well, no
> complex state allowed), as you cannot take any locks,

First: Of course you can take locks. Such a "timed execution" is - just 
like any other thread - still scheduled by the OS and thus follows the 
same rules. A higher priority to make sure an expired timer actually 
preempts other running threads doesn't change this fact.

> and must be re-entrant. This implies you can almost call no function
> at all.

Second: You could call any function you can call safely from within any 
other plain thread.

That's the difference to a "real" signal (where you can merely set some 
variable to be polled later and bail out), and makes it so much nicer 
to use than OS' signals.

So, the semantics would be about the same as in a signal (apart from the 
"softer" timing), but you would have much less restrictions in the 
handler's implementation compared to a real OS signal, which acts more 
like an interrupt.


More information about the fpc-devel mailing list