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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
