On Wed, 2003-07-09 at 15:31, John Myers wrote:
> Daniel McNeil wrote:
>
> >Thoughts?
> >
> >
> I don't think io_queue_run() is particularly worthwhile. Applications
> are much better off coding that loop themselves, so they can control
> such things as how many events they ask for in a call to io_getevents()
> and how they handle process shutdown. Besides, io_queue_run()'s
> handling of EINTR isn't particularly good.
>
> io_queue_run() is basically for legacy apps. Your patch changes its
> signature, which breaks its only use.
>
If any application is using io_queue_run()/io_queue_wait(), it is
wasting a bunch of cpu time because io_queue_wait() is never waiting.
So, yes, this would break any existing application which is using
the currently broken io_queue_wait(). Is there any "legacy" app using
this? How long have the interfaces been around?
If io_queue_run()/io_queue_wait() isn't worthwhile, then it should be
removed. If having a callback interface is worthwhile, I vote for
fixing it. So the choices are:
1. patch kernel to get io_queue_wait() to actually wait. (see my earlier
patch).
2. Change the libaio callback interfaces so that it blocks without
patching the kernel. (This patch does that).
3. remove io_queue_run()/io_queue_wait() if they are not worthwhile.
I agree that the io_getevents() is sufficient, but it doesn't hurt
having the callback interface (if it actually worked correctly).
Daniel
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:33 EST