On 8/20/19 2:29 PM, Bruno Haible wrote:
> Eric Blake wrote:
>> +#if SOCK_CLOEXEC
>> + if (flags & SOCK_NONBLOCK)
>
> Why '#if SOCK_CLOEXEC'?
> Why not '#if SOCK_NONBLOCK'?
Because I made a typo. Thanks for spotting it; will fix shortly.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Eric Blake wrote:
> Hmm, I guess it would be better to make the accept4 module depend on
> nonblocking
I would not like this. The 'nonblocking' module is quite intrusive
(it hooks into many stdio functions, from 'getchar' to 'fprintf').
Few applications use nonblocking file, pipe, or sockets. The
Eric Blake wrote:
> +#if SOCK_CLOEXEC
> + if (flags & SOCK_NONBLOCK)
Why '#if SOCK_CLOEXEC'?
Why not '#if SOCK_NONBLOCK'?
Bruno
On Tue, Aug 20, 2019 at 11:37:27AM -0500, Eric Blake wrote:
> +#if SOCK_CLOEXEC
> + if (flags & SOCK_NONBLOCK)
> +{
> + int fcntl_flags;
> +
> + if ((fcntl_flags = fcntl (fd, F_GETFL, 0)) < 0
> + || fcntl (fd, F_SETFL, fcntl_flags | O_NONBLOCK) == -1)
Can't this call set_no
On 8/20/19 11:37 AM, Eric Blake wrote:
> Ideally, we would improve our replacement to define a
> replacement SOCK_NONBLOCK on all platforms, and teach socket() to
> honor it as well; but that's a bigger task. In the meantime, if the
> platform already has SOCK_NONBLOCK, we should honor it when do
Ideally, we would improve our replacement to define a
replacement SOCK_NONBLOCK on all platforms, and teach socket() to
honor it as well; but that's a bigger task. In the meantime, if the
platform already has SOCK_NONBLOCK, we should honor it when doing a
fallback.
* lib/accept4.c (accept4): If
