| |||||||||||||
Choosing between portability and innovationChoosing between portability and innovationPosted Mar 4, 2011 23:08 UTC (Fri) by foom (subscriber, #14868)In reply to: Choosing between portability and innovation by nevyn Parent article: Choosing between portability and innovation
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.
(Log in to post comments)
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.
|
|||||||||||||