On Wed, May 13, 2009 at 22:50, Coleman Kane <ckane@xxxxxxxxxxxxxxx> wrote: > For some reason the ppoll call always returns -1 w/ EINVAL in this > configuration. I actually anticipate this to be a bug in either Linux or > uClibc... Likely the libc, I did not hear of any such problems somewhere else. What does strace show? > However, while investigating this, I came across the following sequence > of steps performed in udevd.c (line 973): > > fdcount = ppoll(pfd, nfds, NULL, &orig_mask); > sigprocmask(SIG_SETMASK, &orig_mask, NULL); > > Maybe I am missing something, but my reading of the man page indicates > that the following sequence would accomplish the same work, but would be > faster, as it eliminates the restoration of blocked_mask at the end of > the ppoll() call, which then proceeds to be overwritten again to what it > was inside ppoll by the above sigprocmask() call. > > Would it be basically the same to do the following (but faster)? > > sigprocmask(SIG_SETMASK, &orig_mask, NULL); > fdcount = poll(pfd, nfds, -1); If signals happen between this sigprocmask() and the poll(), you go to sleep, even when you need to do work. The use of ppoll() is just the same sequence of operations, but done atomically in the kernel, which prevents the mentioned race. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
