Messages in this thread | | | Date | Thu, 28 Feb 2008 23:32:05 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH 3/3] Consolidate send_sigqueue and send_group_sigqueue |
| |
On Thu, 28 Feb 2008, Roland McGrath wrote:
> That code dates from the original introduction of those two functions. > I can't see any reason why those ever had swapped order of the two checks. > I think it must have just been sloppy coding in the original work. > > I'm not clear on how the already-queued case could ever happen. Do we > really need that check at all? It shouldn't be possible for the timer to > be firing when it's already queued, because it won't have been reloaded. > It only reloads via do_schedule_next_timer after it's dequeued, or because > a 1 return value said it never was queued. Perhaps a timer_settime can > restart it while queued? But I don't think it should. > > I think the rules for send_sigqueue and send_group_sigqueue should match. > Any call that did not result in the signal being queued must return 1. > If it is in fact possible at all that the signal is already queued, then > that case must return 0 if the signal will ever be dequeued. > > Looking at this makes me think we are incorrect in another anal case. > Say the timer signal is blocked and the timer has fired, so it is on the > queue and expects to be reloaded by do_schedule_next_timer at dequeue. > Now, sigaction is used to set that signal to SIG_IGN, so the pending > signal is removed from the queue but not dequeued. Time passes, so the > timer has in theory fired and reloaded several times counted as overruns. > Next, sigaction is used to establish a handler for that signal, and then > we unblock it too. Time continues to pass, but the timer has not been > reloaded after the first firing, and so it never fires with the handled > signal though it now should have done so. This case is at least a bit > pathological. But I'm not sure there is anything in POSIX to exempt us > from making it work correctly. Off hand the change that seems like it > would work is to do the dequeue-time SI_TIMER check at discard time too.
Right. I was working on a fix for that for a different reason. What we really want is a check for such a timer on a transition from SIGIGN to another state. This would allow us to drop the ugly auto rearm code for ignored timers completely. I had some working proof of concept code, but got distracted. Need to find it again and dust if off.
Thanks,
tglx
| |