bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fcntl module


From: Bruno Haible
Subject: Re: fcntl module
Date: Mon, 24 Aug 2009 02:01:07 +0200
User-agent: KMail/1.9.9

Eric Blake wrote:
> So maybe at this point I will regroup a bit and figure out how to replace
> broken fcntl on Unix-y systems, and focus on F_DUPFD_CLOEXEC first.

Now that we have pipe2, accept4, the next step is to combine them with
the *-safer functionality. This overlaps with F_DUPFD and F_DUPFD_CLOEXEC.
So, the actual better primitives are
    dup_ex (int fd, int flags, int minimum)
    pipe2_ex (int fd[2], int flags, int minimum)
    accept4_ex (int s, struct sockaddr *addr, socklen_t *addrlen, int flags, 
int minimum)

(I don't dare calling this dup4, because a new function dup4 might come along
in glibc in a couple of years. We have seen wait3 and wait4 already...)

fcntl (fd, F_DUPFD, arg) is then equivalent to    dup_ex (fd, 0, arg).
fcntl (fd, F_DUPFD_CLOEXEC, arg) is equivalent to dup_ex (fd, O_CLOEXEC, arg).
dup_safer (fd)                   is               dup_ex (fd, 0, 3).

In lib/pipe.c:
dup_safer_noinherit (fd)         is               dup_ex (fd, O_CLOEXEC, 3).
pipe2 then fd_safer_noinherit    is               pipe2_ex (fd, O_CLOEXEC, 3).

With this, fcntl() becomes less important to implement.

> Actually, I'd like to
> see F_DUPFD and F_DUPFD_CLOEXEC be the preferred interfaces (those are
> both POSIX) rather than dup_noinherit (or dup_ex); dup(n) is trivially
> fcntl(n,F_DUPFD,0), so all we are missing is mapping dup_noinherit to
> fcntl(n,F_DUPFD_CLOEXEC,0).

I prefer the dup_ex interface to fcntl, because it supports not only
O_CLOEXEC but also O_TEXT / O_BINARY and possibly other flags in the future.

> > {
> >   unsigned char fds_to_close[4096 / 8];
> 
> 4096 seems magic - can we justify it with <limits.h>, with OPEN_MAX or the
> like?

There's nothing relevant in mingw <limits.h>. I corrected getdtablesize() now
so that it returns 2048 on Windows XP, and defined an OPEN_MAX_MAX locally
that is a conservative guess.

> 8 should be replaced by CHAR_BIT

Done.

> > This code does not preserve the invariant that for any open fd, the flags
> > stored inside MSVCRT for fd contain the bit FNOINHERIT if and only if
> > the handle _get_osfhandle (fd) has the InheritHandle flag set to FALSE.
> 
> Ouch.  Good call.  Paolo's comment also holds about setting FD_CLOEXEC
> being easier than clearing, if we are okay with child processes starting
> with an open fd tied to an invalid handle.

Honestly, I don't believe many types of child processes will handle this
gracefully. Simply because it's not well tested in the Windows world. The
only situation so far, in which open file descriptors with INVALID_HANDLE_VALUE
appear, is as standard file descriptors in weird situations.

> >      O_APPEND unknown!
> 
> Is there seriously no way to ascertain whether an fd on Woe32 is in append
> mode?  Wow, that will make implementing F_GETFL tough.

I don't see any way without peeking into the unportable _pioinfo array and
without writing something to the file descriptor.

But that could be OK: One can document that F_GETFL loses the O_APPEND flag.
It's hard to imagine someone relying on this functionality.

> We've already overridden open() and friends for mingw, so we could
> implement O_APPEND tracking for all fds created within our own process
> (but not those inherited from a parent process).

I'd say, this is overkill.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]