Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

But no other syscall interface presumes that you're directly twiddling kernel structs and I struggle to think of any other syscall that operates on fds, for which you need to keep in mind that it actually operates on internal kernel structs.

It would be trivial for the kernel to attach the epoll struct to the file descriptor and give you a close notification when the descriptor is closed (even if there are other open descriptors to the same file), but it's really hard to emulate that behaviour in userland, except this is the precise behaviour most people want! The only way to emulate this behaviour is to write a full abstraction over all file syscalls and make sure you never ever call them directly.



The entire point of my post was to say yes, that all the other/all system calls do work with kernel structs internally ones the system call passes into kernel land. Again, please do not forget a system call is a controlled exposure to kernel code -- it is not a library.

Every function call works the same way as epoll works ounces the fd is translated into a actual kernel structure. Conflating the fd with the file is where all assumptions go wrong. The fd is the means you tell epoll what file you want to be notified on events about. A file is NOT closed until there are no more references. This is simply how linux works. To change that would be non trivial and break years of software.

Let's explore your idea a bit more. If you were to want to know when a "fd" was closed, what would you be using that for? You really want to know when a file was closed right? If so, any code that you execute after you get the close on the fd would be wrong and cause even more surprising results. This is because the file is not actually closed. It is open. Whoever has the remaining handles can modify it while you think the file is closed -- that is a bug.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: