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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
