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 06:02, Eric Blake wrote:
> According to Corinna Vinschen on 1/14/2010 4:57 AM:
> >> time to do that via the O_CLOEXEC flag.
> > 
> > Hang on, the file is closed anyway after the mmap call succeeded.
> > That's not true for sem_open and shm_open, though.
> 
> Well, on Linux, it looks like sem_open does not need to keep the fd open.
>  It all boils down to the question of any API that can hand a new fd back
> to the user should have the ability to protect said fd with O_CLOEXEC at
> creation time.
> 
> > 
> > However, what kind of cleanup did you mean?  There's no EINVAL specified
> > in POSIX for invalid open flags and invalid flags are already filtered
> > out before calling open.
> 
> 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.


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]