Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 8 Dec 2014 11:00:10 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [RFC] EINTR and PC loser-ing library design

On Mon, Dec 08, 2014 at 04:49:00PM +0100, Laurent Bercot wrote:
> On 08/12/2014 16:28, Rich Felker wrote:
> >The only such exception I'm aware of is that POSIX allows, but does
> >not require, select to fail with EINTR even when SA_RESTART is used.
> 
>  What do you say of poll ?
> 	The poll() function shall fail if:
> 	[EINTR]
> 	     A signal was caught during poll().
> 
>  Note that it is "shall", not "may".
> 
>  One may argue that the SA_RESTART behaviour has priority over "poll() shall
> fail with EINTR if a signal is caught", as with other functions such as
> read(), but one may also argue that, just as with select(), it makes perfect
> sense to *not* restart poll() when a signal is caught, since time has elapsed
> since the original call and the application may want to update the timeout
> values, so the exception that applies to select should also apply to poll.

Since poll does not have explicit text overriding the text on
SA_RESTART, my understanding is that it's required to obey SA_RESTART.
However it's unclear because most functions which have EINTR as a
specified error use the phrase "the function was interrupted
[before]..." (in particular, the word "interrupted" appears) whereas
the text for poll merely says "a signal was caught". This should
probably be clarified. Note that the Linux behavior is that poll
restarts automatically. I'm not sure about select.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.