RE: slow open() calls and o_nonblock

["David Schwartz" <davids@webmaster.com>]

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