No NONBLOCK flag for dup3() or epoll_create1()?

No NONBLOCK flag for dup3() or epoll_create1()?

[Michael Kerrisk]

Ulrich

I've been doing some testing (2.6.27-rc3) of your new
file-descriptor-creating syscalls that accept flags.  According to

http://udrepper.livejournal.com/20407.html

all of the system calls should accept a *_NONBLOCK flag.  All of them do,
except for two:
dup3(olfd, newfd, flags)
and
epoll_create1(flags).

For epoll_create1() this certainly appears to be an oversight, since I can't
think of a reason not to support *_NONBLOCK.

For dup3() it is perhaps also an oversight.  However, it's not really clear
to me whether supporting O_NONBLOCK makes sense, since that would change the
file status flags of the open file description that is (also) referred to by
oldfd.  (Furthermore, given a open file description for which O_NONBLOCK is
already enabled, it is not possible to make a dup3() call that disables
O_NONBLOCK, which is an odd asymmetry in the API.)  What are your thoughts on
this?

Cheers,

Michael

Re: No NONBLOCK flag for dup3() or epoll_create1()?

[Davide Libenzi]

On Wed, 20 Aug 2008, Michael Kerrisk wrote:

> Ulrich
> 
> I've been doing some testing (2.6.27-rc3) of your new
> file-descriptor-creating syscalls that accept flags.  According to
> 
> http://udrepper.livejournal.com/20407.html
> 
> all of the system calls should accept a *_NONBLOCK flag.  All of them do,
> except for two:
> dup3(olfd, newfd, flags)
> and
> epoll_create1(flags).
> 
> For epoll_create1() this certainly appears to be an oversight, since I can't
> think of a reason not to support *_NONBLOCK.

Traditionally the no-wait epoll_wait() has been achieved with a zero 
timeout, but _NONBLOCK support can be easily added if seen as necessary.



- Davide

Re: No NONBLOCK flag for dup3() or epoll_create1()?

[Michael Kerrisk]

Ping!

On Wed, Aug 20, 2008 at 6:49 PM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
> Ulrich
>
> I've been doing some testing (2.6.27-rc3) of your new
> file-descriptor-creating syscalls that accept flags.  According to
>
> http://udrepper.livejournal.com/20407.html
>
> all of the system calls should accept a *_NONBLOCK flag.  All of them do,
> except for two:
> dup3(olfd, newfd, flags)
> and
> epoll_create1(flags).
>
> For epoll_create1() this certainly appears to be an oversight, since I can't
> think of a reason not to support *_NONBLOCK.
>
> For dup3() it is perhaps also an oversight.  However, it's not really clear
> to me whether supporting O_NONBLOCK makes sense, since that would change the
> file status flags of the open file description that is (also) referred to by
> oldfd.  (Furthermore, given a open file description for which O_NONBLOCK is
> already enabled, it is not possible to make a dup3() call that disables
> O_NONBLOCK, which is an odd asymmetry in the API.)  What are your thoughts
> on
> this?
>
> Cheers,
>
> Michael
>
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: No NONBLOCK flag for dup3() or epoll_create1()?

[Ulrich Drepper]

On Wed, Aug 20, 2008 at 9:49 AM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
> I've been doing some testing (2.6.27-rc3) of your new
> file-descriptor-creating syscalls that accept flags.  According to
>
> http://udrepper.livejournal.com/20407.html
>
> all of the system calls should accept a *_NONBLOCK flag.

This was never the intention.


> For epoll_create1() this certainly appears to be an oversight, since I can't
> think of a reason not to support *_NONBLOCK.

I can.  There is already a method to not block (zero timeout).  We
should not provide multiple ways to get the same functionality.  It
would require changes in the epoll code as well.  That's not worth it.


>  (Furthermore, given a open file description for which O_NONBLOCK is
> already enabled, it is not possible to make a dup3() call that disables
> O_NONBLOCK, which is an odd asymmetry in the API.)

That's why I didn't add support for the flag.  It's hardly useful to
add this support.

Re: No NONBLOCK flag for dup3() or epoll_create1()?

[Michael Kerrisk]

On Mon, Sep 1, 2008 at 5:34 PM, Ulrich Drepper <drepper@gmail.com> wrote:
> On Wed, Aug 20, 2008 at 9:49 AM, Michael Kerrisk
> <mtk.manpages@googlemail.com> wrote:
>> I've been doing some testing (2.6.27-rc3) of your new
>> file-descriptor-creating syscalls that accept flags.  According to
>>
>> http://udrepper.livejournal.com/20407.html
>>
>> all of the system calls should accept a *_NONBLOCK flag.
>
> This was never the intention.

All of the below makes some sense, but is at odds with what you posted
on your blog entry, which documents *_NONBLOCK for both
epoll_create1() and dup3().  Thus, I needed to check with you since
the "intention" stated in the blog post differs from the actual
implementation.

>> For epoll_create1() this certainly appears to be an oversight, since I can't
>> think of a reason not to support *_NONBLOCK.
>
> I can.  There is already a method to not block (zero timeout).  We
> should not provide multiple ways to get the same functionality.

Though, one reason to do so would be consistency with the other
changed APIs.  (There are many cases where *ix API provides more than
one way of getting the same functionality.)

> It
> would require changes in the epoll code as well.  That's not worth it.
>
>
>>  (Furthermore, given a open file description for which O_NONBLOCK is
>> already enabled, it is not possible to make a dup3() call that disables
>> O_NONBLOCK, which is an odd asymmetry in the API.)
>
> That's why I didn't add support for the flag.  It's hardly useful to
> add this support.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: No NONBLOCK flag for dup3() or epoll_create1()?

[Michael Kerrisk]

On Mon, Sep 1, 2008 at 5:34 PM, Ulrich Drepper <drepper@gmail.com> wrote:
> On Wed, Aug 20, 2008 at 9:49 AM, Michael Kerrisk
> <mtk.manpages@googlemail.com> wrote:
>> I've been doing some testing (2.6.27-rc3) of your new
>> file-descriptor-creating syscalls that accept flags.  According to
>>
>> http://udrepper.livejournal.com/20407.html
>>
>> all of the system calls should accept a *_NONBLOCK flag.
>
> This was never the intention.

All of the below makes some sense, but is at odds with what you posted
on your blog entry, which documents *_NONBLOCK for both
epoll_create1() and dup3().  Thus, I needed to check with you since
the "intention" stated in the blog post differs from the actual
implementation.

>> For epoll_create1() this certainly appears to be an oversight, since I can't
>> think of a reason not to support *_NONBLOCK.
>
> I can.  There is already a method to not block (zero timeout).  We
> should not provide multiple ways to get the same functionality.

Though, one reason to do so would be consistency with the other
changed APIs.  (There are many cases where *ix API provides more than
one way of getting the same functionality.)

> It
> would require changes in the epoll code as well.  That's not worth it.
>
>
>>  (Furthermore, given a open file description for which O_NONBLOCK is
>> already enabled, it is not possible to make a dup3() call that disables
>> O_NONBLOCK, which is an odd asymmetry in the API.)
>
> That's why I didn't add support for the flag.  It's hardly useful to
> add this support.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html