Since I still think that the many-thousands potential async operations
coming from network sockets are better handled with a classical event
machanism [1], and since smooth integration of new async syscall
into the
standard POSIX infrastructure is IMO a huge win, I think we need to
have a
"bridge" to allow async completions being detectable through a
pollable
(by the mean of select/poll/epoll whatever) device.
Ugh, I'd rather not if we don't have to.
It seems like you could get this behaviour from issuing a poll/select
(really?)/epoll as one of the async calls to complete. (And you
mention this in a later email? :))
Part of my thinking on this is that we might want it to be really
trivial to create and wait on groups of ops.. maybe as a context.
One of the things posix AIO wants is the notion of submitting and
waiting on a group of ops as a "list". That sounds like we might be
able to implement it by issuing ops against a context, created as
part of the submission, and then waiting for it to drain.
Being able to wait on that with file->poll() obviously requires
juggling file-> associations which sounds like more weight than we
might want. Or it'd be optional and we'd get more moving parts and
divergent paths to test.
So, sure, it's possible and not terribly difficult, but I'd rather
avoid it if people can be convinced to get the same behaviour by
issuing an async instance of their favourite readiness syscall.
- z
-
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/
