This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dup3/O_CLOEXEC/F_DUPFD_CLOEXEC


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]