[vlc-devel] Re: vlc: svn commit r19402 (fenrir)
rem at videolan.org
Sat Mar 24 12:19:22 CET 2007
Le samedi 24 mars 2007 02:09, Laurent Aimar a écrit :
> > I am not convinced this is correct at all. Which signals is causing
> > a problem? polls are not supposed to be interrupted in the first
> > place, or there is likely a bug somewhere else. Eating up a signal
> > silently is plain wrong.
> Well from man poll:
> The poll() function will fail if:
> EINTR A signal was caught during the poll() function.
I did not say this cannot happen in the general case. But VLC blocks
signals it handles, so they cannot occur during poll() - or anything
else for that matter. The remaining ones will either crash the program
(so they poll won't have a chance to return) or be ignored (in which
case poll() ought not to be interrupted AFAIK).
Another possibility lies in some libraries installing its own signal
handlers (X11 output?), or that our signal mask is incomplete. But
then, the signals ought to be delivered to the thread running that
library, not to another random thread doing network I/O (and well,
libraries should never install signal handlers anyway). Then, eating up
EINTR in poll() is likely merely a work-around for a bug lying
> And on my computer it happens (not that often but ...)
> I haven't used poll very much but for it seems similar to select man
> page. For select we handle it and I am sure it is needed.
Yeah, signal handling semantics are identical with select() and poll().
Which is to say a broken/racy handling, unless signals are completely
blocked. The reason for switching to poll was support for more than
FD_SETSIZE open files, where FD_SET silently causes a buffer overflow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the vlc-devel