Re: Fw: epoll and fork()

Re: Fw: epoll and fork()

[Davide Libenzi]

>
> 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?

epoll does register the underlying file* not the fd, so this is the 
expected behaviour. Inheriting an fd, and epoll is no exception, simply 
bumps a counter, so both parent and child epoll fd shares the same context. 
Sorry but what behaviour do you expect by unregistering an fd pushed by 
the parent from inside a child? Events work exactly the same. Since the 
context is shared, events are delivered only once.



- Davide

Re: Fw: epoll and fork()

[Chris Friesen]

Davide Libenzi wrote:

> Sorry but what behaviour do you expect by unregistering an fd pushed by 
> the parent from inside a child? Events work exactly the same. Since the 
> context is shared, events are delivered only once.

For principle of least surprise, I would expect that the refcounts would 
be bumped up so that the child could deregister without affecting the 
parent.

Closing the fd in the child doesn't affect the fd in the parent. 
Removing an fd from an fd_set in the child doesn't affect the fd_set in 
the parent.  Unregistering an fd from an epoll set in the child 
shouldn't affect the parent either.

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: Fw: epoll and fork()

[Ben]

On Tue, 2 Mar 2004, Davide Libenzi 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?
>
> epoll does register the underlying file* not the fd, so this is the
> expected behaviour. Inheriting an fd, and epoll is no exception, simply
> bumps a counter, so both parent and child epoll fd shares the same context.
> Sorry but what behaviour do you expect by unregistering an fd pushed by
> the parent from inside a child? Events work exactly the same. Since the
> context is shared, events are delivered only once.

It seems unintuitive, although having heard the arguments, I can
understand why it works this way.

I was thinking that epoll should behave like a file descriptor (i.e. a
child can close an inherited fd without affecting the parent), simply
because the only connection a process has with epoll is the file
descriptor. I suppose if you think of epoll_ctl() and epoll_wait() as
write()s and read()s on the file descriptor, then it makes sense that
these operations would affect both processes.

It still feels 'wrong' though :)


Ben

Re: Fw: epoll and fork()

[Mark Mielke]

On Tue, Mar 02, 2004 at 03:38:04PM +0000, Ben wrote:
> I was thinking that epoll should behave like a file descriptor (i.e. a
> child can close an inherited fd without affecting the parent), simply
> because the only connection a process has with epoll is the file
> descriptor. I suppose if you think of epoll_ctl() and epoll_wait() as
> write()s and read()s on the file descriptor, then it makes sense that
> these operations would affect both processes.
> It still feels 'wrong' though :)

If you read from a file descriptor in one process, the file pointer is
moved, and the read from the other process will not get the same bytes
twice.

Seems 'right', although inconvenient might be a better conclusion than
unintuitive... :-)

I wonder if this 'feature' could be taken advantage of somehow? One could
monitor the state of a file descriptor without having access to the file
descriptor... Hmm...

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: Fw: epoll and fork()

[Davide Libenzi]

On Tue, 2 Mar 2004, Ben wrote:

> child can close an inherited fd without affecting the parent), simply
> because the only connection a process has with epoll is the file
> descriptor. I suppose if you think of epoll_ctl() and epoll_wait() as
> write()s and read()s on the file descriptor, then it makes sense that
> these operations would affect both processes.

Note that if the parent or the child does close an fd, this does not get 
automatically unregistered from the epoll fd of the other task. An fd can 
be unregistered from an epoll fd either explicitly with an epoll_ctl() or 
implicitly when the use count of the underlying file* goes to zero.



- Davide

Re: Fw: epoll and fork()

[Davide Libenzi]

On Tue, 2 Mar 2004, Chris Friesen wrote:

> Davide Libenzi wrote:
> 
> > Sorry but what behaviour do you expect by unregistering an fd pushed by 
> > the parent from inside a child? Events work exactly the same. Since the 
> > context is shared, events are delivered only once.
> 
> For principle of least surprise, I would expect that the refcounts would 
> be bumped up so that the child could deregister without affecting the 
> parent.
> 
> Closing the fd in the child doesn't affect the fd in the parent. 
> Removing an fd from an fd_set in the child doesn't affect the fd_set in 
> the parent.  Unregistering an fd from an epoll set in the child 
> shouldn't affect the parent either.

There are two issues here. One is the fact that *explicitly* unregistering 
the fd in one task and expecting the other one to act as if it was 
registered could be considered a sign of a not clean interaction between 
parent and child. The ref-count thing would not work because it is the 
kernel that automatically and directly bumps the ref count, w/out calling 
any f_op->xxxx() (like for example use/release). So epoll would have to 
hook the file get function, detect if the fd is inside an epoll fd, and 
take proper action by bumping its count. IMO it is not worth even 
considering.



- Davide