On Tue, Apr 21, 2009 at 10:02:19AM -0400, Oleh Derevenko wrote:
> By Brian Stecher:
> > We only expire a maximum of 50 timers on each clock tick (to minimize
> > latency), so we should still have plenty of critical heap.
> 
> Another funny thing is that it's enough to write a simple program that will schedule 50 timers periodically for each 
tick with event handlers just doing nothing and this will break down the system completely as noone else will have their
 timer working. :)

Actually no. After the timers fire, they'll be placed back on the active
list *after* the timers that got skipped the first time since they now
have a later firing time. The next clock tick will process the delayed
timers before getting back to your malicious 50.

-- 
Brian Stecher (bstecher@qnx.com)        QNX Software Systems
phone: +1 (613) 591-0931 (voice)        175 Terence Matthews Cr.
       +1 (613) 591-3579 (fax)          Kanata, Ontario, Canada K2M 1W8

Aha! That returns us to previous topic and indicates that the statement "...so we should still have plenty of critical 
heap" is incorrect at all. There can be lots of processes and they can scheduled timers in a manner that critical heap 
ends even though each of them is handling events of its own and does not do anything illegal.

> If the timeout is pending at timer_settime then the processing of the event 
> delivery is completed before
> the settime is performed.
> 
> Also, 50 is just the limit of timers to be delivered in the clock interrupt - 
> further timers are processed by
> adding an interrupt event such that any left-over timer firings are handled as
>  the kernel exits, but before
> user threads run.
> 
> Oleh Derevenko wrote:
> > By Brian Stecher:
> >> We only expire a maximum of 50 timers on each clock tick (to minimize
> >> latency), so we should still have plenty of critical heap.
> > 
> > So, this bears an interesting question. Consider you have more than 50 
> timers scheduled for the same expiration time and you expire only first 50 and
>  leave few more for the next tick. Now, before the next tick I call 
> TimerSetTime() for one of those few delayed timers. What do I get in oitime 
> parameter? Arithmetically I should get zero (or even a negative value) but, 
> accordingly to documentation, zero is an indicator that the timer has already 
> expired and a signal or pulse has already been queued for the recipient.  This
> , obviously is not the case and the event will not be queued at all because I 
> change timer expiration time with my current call. Obviously it will lead to 
> malfunction in the program logic.
> > Any comments on this situation?