Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <9DFC885B-7454-4F81-A2BF-AED124FF80AD@gmail.com>
Date: Sat, 24 Feb 2018 11:45:16 +0100
From: Julien Ramseier <j.ramseier@...il.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] sigtimedwait: allow failing with EINTR



> Le 23 févr. 2018 à 22:45, Rich Felker <dalias@...c.org> a écrit :
> 
> On Fri, Feb 23, 2018 at 01:09:35PM +0100, Julien Ramseier wrote:
>> According to POSIX, sigtimedwait(2) is allowed to fail
>> with EINTR, while sigwait(3) is not, so move the retry loop there.
>> ---
> 
> This is a "may fail", not a "shall fail". Generally we prefer not to
> support EINTR in cases where it's optional, since getting rid of them
> with retry loops makes it safe to run on old kernels or
> pseudo-linux-compat systems where SA_RESTART semantics were/are not
> actually conforming. Is there a reason you want it to fail with EINTR?
> 
> Rich

Some apps seem to rely on this, notably Python where a test case expects
sigtimedwait to be interrupted when a SIGALRM is fired.

I cannot find another case in musl where EINTR is inhibited
(while being allowed by POSIX), are there any?

- Julien

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.