This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
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