Re: slow open() calls and o_nonblock

["Aaron Wiebe" <epiphani@gmail.com>]

Replying to David Schwartz here.. (David, good to hear from you again
- haven't seen you around since the irc days :))

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.

> You need either threads or a working asynchronous system call interface.
> Short of that, you need your own NFS client code.

This is exactly my point - there is no asynchronous system call to do
this work, to my knowledge.  I will likely fix this in my own code
using threads, but I see using threads in this case as working around
that lack of systems interface.  Threads, imho, should be limited to
cases where I'm using them to distribute load across multiple
processors, not because the kernel interfaces for IO cannot support
nonblocking calls.

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.

(And I did actually consider writing my own NFS client for about 5 minutes.)

Thanks for the response!
-Aaron