[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.
Vinzent.
More information about the fpc-devel
mailing list