Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: slow open() calls and o_nonblock | Date | Mon, 4 Jun 2007 13:32:53 -0700 |
| |
Aaron Wiebe wrote:
> David Schwartz wrote:
> > There is no way you can re-try the request. The open must > > either succeed or > > not return a handle. It is not like a 'read' operation that has > > an "I didn't > > do anything, and you can retry this request" option.
> > If 'open' returns a file handle, you can't retry it (since it > > must succeed > > in order to do that, failure must not return a handle). If you 'open' > > doesn't return a file handle, you can't retry it (because, > > without a handle, > > there is no way to associate a future request with this one, if > > it creates a > > file, the file must not be created if you don't call 'open' again).
> I understand, but this is exactly the situation that I'm complaining > about. There is no functionality to provide a nonblocking open - no > ability to come back around and retry a given open call.
I agree. I'm addressing why things can't "just work", not arguing that they aren't broken or should stay broken. ;)
I think a good solution would be to re-use the 'connect' and 'shutdown' calls. You would need a new asynchronous flag to 'open' that would mean, *really* don't block. You would have to follow up with 'connect' to complete the actual opening -- the 'open' would just assign a file descriptor (unless it could complete or error immediately, of course).
To asynchronously close such a socket, you simply call 'shutdown'. Once the 'shutdown' completes, 'close' would be guaranteed not to block.
Obviously, being able to 'poll' or 'select' would be a huge plus (while an 'open' or 'close' is in progress, of course, otherwise it would always return immediate availability).
I think this covers all the bases and the only ugly API change is an extra 'open' flag. (Which I think is unavoidable.)
> I'm speaking to my ideal world view - but any application I write > should not have to wait for the kernel if I don't want it to. I > should be able to submit my request, and come back to it later as I so > decide.
A working generic asynchronous system call interface would be the best solution, I think. But that may be further off than just an asynchronous file open/close interface.
> (And I did actually consider writing my own NFS client for about > 5 minutes.)
Yeah, what a pain that would be. The obvious counter-argument to what I propose above is that it doesn't handle reads and writes, so why bother with a complex partial solution?
DS
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |