Re: epoll and fork()

["Richard B. Johnson" <root@chaos.analogic.com>]

On Tue, 2 Mar 2004, Mihai RUSU wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 2 Mar 2004, Ben wrote:
>
> > Is there a defined behaviour for what happens when a process with an epoll
> > fd forks?
> >
> > I've an app that inherits an epoll fd from its parent, and then
> > unregisters some file descriptors from the epoll set. This seems to have
> > the nasty side effect of unregistering the same file descriptors from the
> > parent process as well. Surely this can't be right?
> >
> > This is on 2.6.2.
>
> Currect me if Im wrong but...
>
> After a fork() arent all the parent's fds shared with the children ? This
> means that both processes can access the same fds right ? So the epoll fd
> (beeing just another fd as any other) is too shared between parent and
> child ? Which would mean both parent and child will "control" the same
> epoll kernel struct when doing epoll_ctl on it ?
>
> > Ben
>

The child's fds are separate, though. The parent can close
its fds without affecting the child's and the child can close
its fds without affecting the parent. Given that, suppose that
the fds related to a terminal. If the child changed the terminal
attributes, this would certainly affect the parent's terminal
since they are the same. It is possible that epoll handles
these attributes the same way and it is likely that such
behavior is "undefined". A fix may be for the child to dup()
the fds and set up its own epoll_ctl using them. If the epoll
relates to a controlling terminal, it is possible that if the
child executes setsid(), becomes its own session leader, then
the epoll  problem will go away because the parent's controlling
terminal and the child's controlling terminal become divorced.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.