On 10/20/09, Marco d'Itri <m...@linux.it> wrote:
> On Oct 20, Torsten Crass <torsten.cr...@ebiology.de> wrote:
>
>>>> read(7, "", 128) = 0
>>>> poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6,
>>>> events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5,
>>>> 3000) = 1 ([{fd=7, revents=POLLIN}])
> So for some reason the signalfd(2) fd keeps returning nothing (which is
> an error) with your self-compiled 2.6.22.20071006 kernel.
> 2.6.22 is supposed to work, so I will keep this bug open to see if
> anybody else is affected.
>
> I see that udevd, unlike the example in the man page, is quite
> permissive in checking the results of the read.
> Maybe if read(2) returns zero it should just fail.
>
> size = read(pfd[FD_SIGNAL].fd, &fdsi, sizeof(struct signalfd_siginfo));
> if (size == sizeof(struct signalfd_siginfo))
> handle_signal(udev, fdsi.ssi_signo);
>
Sounds good to me. A zero return from read should always mean EOF.
Whatever this means for a signalfd, it's not "ignore this result and
try again". The manpage seems to exclude it anyway.
"If none of the signals in mask is pending for the process, then
the read(2) either blocks until one of the signals in mask is
generated for the process, or fails with the error EAGAIN if the file
descriptor has been made non-blocking."
Alan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
