Recent Features
| |||||||||||||
Choosing between portability and innovationChoosing between portability and innovationPosted Mar 4, 2011 22:11 UTC (Fri) by nevyn (subscriber, #33129)In reply to: Choosing between portability and innovation by foom Parent article: Choosing between portability and innovation
> No, it really wasn't misleading. The userspace-visible key *is* the fd.
> You're required to pass that in, that's what epoll uses to look up the > file object, it will always pass that back
Yes, you need an fd to register/change the epoll events. But it isn't ever passed back:
epoll_wait() returns a list of "struct epoll_event", which is defined as:
struct epoll_event
...epoll_data_t is the union I talked about before, so you can use a pointer or a number for your callback data. You don't get the fd back from the API, unless you use that as your callback data but if you do that it's just "a number" ... so I wouldn't expect the kernel to do anything special with it.
(Log in to post comments)
Choosing between portability and innovation Posted Mar 4, 2011 23:08 UTC (Fri) by foom (subscriber, #14868) [Link]
Okay, I must apologize, you are completely right.
I was getting myself mixed up with kqueue's API (which actually does have you specify a struct containing both the fd and userdata), and then mis-reread the epoll docs. (As you might be able to tell, I always passed the fd as the user data. :))
However, that doesn't change the main point I wanted to make, which is that it ought to be tracking fds internally instead of files -- I don't want it to do anything special with the value it returns, I want it to stop watching (and tell me that it did stop watching), if the *fd* I originally gave is closed, not if the underlying file is closed. Returning events on a file that I no longer have a handle for in the current process is annoying.
Choosing between portability and innovation Posted Mar 6, 2011 19:04 UTC (Sun) by intgr (subscriber, #39733) [Link]
> However, that doesn't change the main point I wanted to make, which is
> that it ought to be tracking fds internally instead of files
> I want it to stop watching (and tell me that it did stop watching), if
Seriously, if you want it to stop watching, you use EPOLL_CTL_DEL before closing a file descriptor. The implicit deregister-on-close() is just a safety net -- because it's the only sane thing that the kernel can do when you have watches on a file that's being closed. It's not intended to be used that way.
You tried to spin it as a "*HUGE* misdesign", but in practice it's just a trivial edge case that shouldn't affect real applications. Wouldn't be the first time *BSD people criticize parts of Linux they don't actually understand.
|
|||||||||||||