>
> 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
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
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
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/
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