Actually, lets see if I can summarize this more generically... I realize I'm suggesting something that probably would be a massive undertaking, but ..
Regular files are the only interface that requires an application to wait. With any other case, the nonblocking interfaces are fairly complete and easy to work with. If userspace could treat regular files in the same fashion as sockets, life would be good. I admittedly do not understand internal kernel semantics in the differences between a socket and a regular file. Why couldn't we just have a different 'socket type' like PF_FILE or something like this? Abstracting any IO through the existing interfaces provided to sockets would be ideal from my perspective. The code required to use a file through these interfaces would be more complex in userspace, but the abstraction of the current open() itself could simply be an aggregate of these interfaces without a nonblocking flag. It would, however, fix problems around issues with event-based applications handling events from both disk and sockets. I can't trigger disk read/write events in the same event handlers I use for sockets (ie, poll or epoll). I end up having two separate event handlers - one for disk (currently using glibc's aio thread kludge), and one for sockets. I'm sure this isn't a new idea. Coming from my own development backround that had little to do with disk, I was actually surprised when I first discovered that I couldn't edge-trigger disk IO through poll(). Thoughts, comments? -Aaron On 6/4/07, Aaron Wiebe <[EMAIL PROTECTED]> wrote:
On 6/4/07, Trond Myklebust <[EMAIL PROTECTED]> wrote: > > So exactly how would you expect a nonblocking open to work? Should it be > starting I/O? What if that involves blocking? How would you know when to > try again? Well, theres a bunch of options - some have been suggested in the thread already. The idea of an open with O_NONBLOCK (or a different flag) returning a handle immediately, and subsequent calls returning EAGAIN if the open is incomplete, or ESTALE if it fails (with some auxiliary method of getting the reason why it failed) are not too far a stretch from my perspective. The other option that comes to mind would be to add an interface that behaves like sockets - get a handle from one system call, set it nonblocking using fcntl, and use another call to attach it to a regular file. This method would make the most sense to me - but its also because I've worked with sockets in the past far far more than with regular files. The one that would take the least amount of work from the application perspective would be to simply reply to the nonblocking open call with EAGAIN (or something), and when an open on the same file is performed, the kernel could have performed its work in the background. I can understand, given the fact that there is no handle provided to the application, that this idea could be sloppy. I'm still getting caught up on some of the other suggestions (I'm currently reading about the syslets work that Zach and Ingo are doing), and it sounds like this is a common complaint that is being addressed through a number of initiatives. I'm looking forward to seeing where that work goes. -Aaron
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/