dup3/O_CLOEXEC/F_DUPFD_CLOEXEC

[Corinna Vinschen]

On Jan 14 17:09, Corinna Vinschen wrote:
> On Jan 14 08:39, Pierre A. Humblet wrote:
> > At 08:17 AM 1/14/2010, Corinna Vinschen wrote:
> > >On Jan 14 06:02, Eric Blake wrote:
> > >> In a multi-threaded app, any fd that is opened only temporarily, such as
> > >> the one in mq_open, should be opened with O_CLOEXEC, so that no other
> > >> thread can win a race and do a fork/exec inside the window when the
> > >> temporary fd was open.  So even though mq_open does not leak an fd to the
> > >> current process, it should pass O_CLOEXEC as part of its internal open()
> > >> call in order to avoid leaking the fd to unrelated child processes.
> > >
> > >Uh, ok, that makes sense.
> > >
> > >I'll send a revised patch later today.  It will also include the pipe2
> > >implementation.
> > 
> > For the same reason we should also have SOCK_CLOEXEC, and
> > SOCK_NONBLOCK while we are at it. I would use them in minires.
> 
> Sure, but probably not yet, as far as my hack time is concerned.  But
> of course SHTDI, PTC, and all that.  I'd be glad for it, actually.

It was simpler than I anticipated.  I just applied a patch to implement
accept4, and SOCK_NONBLOCK as well as SOCK_CLOEXEC for socket,
socketpair and accept4.


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat