Re: [rfc] epoll interface change and glibc bits ...

[Mark Mielke <mark@mark.mielke.cc>]

On Wed, Nov 20, 2002 at 03:09:19AM +0000, Jamie Lokier wrote:
> [ ... regarding 'struct epollfd' ('struct epoll_fd'?) ... ]
> What value does the `fd' field have when a file descriptor being
> polled has been renumbered (by dup/close or dup2/close or
> fcntl(F_DUPFD)/close or passing through a unix domain socket)?

As long as the kernel doesn't freeze up or leak memory, I believe it is
the responsibility of the application code to ensure that the correct
file descriptors are registered (and deregistered). If the application
code does screwy things, it should expect a little bit of undefined
behaviour.

> The `fd' field, on the other hand, is not guaranteed to correspond
> with the correct file descriptor number.  So.... perhaps the structure
> should contain an `obj' field and _no_ `fd' field?

Whether the 'fd' field is in kernel space or user space or both does
not really affect the ability of the application code to be able to
perform dup() operations without needing to change references to the
'fd'. For the people that do not wish to use the 'obj' field, the 'fd'
field will be more natural. (Anybody who dups a file descriptor, and
then tells the event loop to watch both file descriptors, is asking for
trouble under any scheme...)

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/