Re: signal queue resource - Posix timers

[William Lee Irwin III <wli@holomorphy.com>]

On Wed, May 28, 2003 at 03:01:17PM -0700, Ulrich Drepper wrote:
> That's not really how you can interpret this.  At the time timer_create
> is it is not know when the timer expires and whether it's a repeating
> timer.  Therefore it is not correct to assume that if timer_create
> succeeds the resources to always deliver the signal are available.
> The shall-error in the standard just covers the case if there is really
> no way this can be made working.  For instance, some implementation
> might allocate to each process using timer_create N signal slots.  The
> whole system could have only N * M slots.
> Because there is no fixed limit (or better said: no guaranteed minimal
> number of signal slots) in Linux this error doesn't apply at all.

The inability to prevent events from coming in faster than one can
process them does create an escape hatch so one doesn't have to handle
this case because it doesn't specify that minimum. Perhaps the
criterion for merging should be if some application is negatively
affected?

But I'm not convinced this would harm anything if merged beforehand.
It's also nice to exert explicit control over competition for memory.


-- wli