Re: slow open() calls and o_nonblock

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

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 <epiphani@gmail.com> wrote:
> On 6/4/07, Trond Myklebust <trond.myklebust@fys.uio.no> 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 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/