On Wed, 11 Feb 2015, Dave Mielke wrote: > Thanks. We do take care to block the signal for all other threads just in case. > > Regarding the possibility of signalfd delivering the signal too early: Wouldn't > it still be true that something within the usbfs code would still need to be > doing something to trigger that behaviour? You'd think so. Or maybe your program can do something to trigger it. > If usbfs really never does anything > to deliver the completion signal until a urb has actually completed then what > might it be doing to trigger a signalfd notificatoin earlier than that? I have no idea. > Some information that may be helpful: > > There's a significant difference in the way a signal handler is used versus the > way signalfd notifications are used. That difference is that the signal is > unblocked when a signal handler is used (so that the handler can catch it) but > is blocked when signalfd notifications are used (so that a handler won't catch > it). This difference offers a possible explanation. > > Is it possible that usbfs sets up the signal right away, but blocks it until > the URB completes? I don't know what "setting up a signal" would involve. In any case, usbfs takes no action regarding signals (except to store a copy of the signal number and the pid and security credentials of the submitting task) when an URB is submitted. > If so, the signal would remain pending and a signal handler > would get it at the right time whereas a signalfd notification would occur > immediately. Nope, the signal isn't raised until the URB completes. In fact, the error code in si_errno reflects the URB's completion status, so it _can't_ be set before the URB completes. Does the poll return immediately after the URB is submitted, or is there a delay? What if you try calling poll _before_ the URB is submitted? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
