> > the _current_ implementation. There is nothing that says you cannot
> > implement aio_*() with a pool of threads and your 'slice up the select
> > space into small pieces and make pieces migrate to get better balance'
> > concept ...
>
> How do you slice this up in the face of blocking file I/O? Once a
> thread starts a read on a regular file, there it sits. I suppose you
> could resort to trickery and fstat(2) FDs and if they are sockets, use
> poll(2) as the basis for dispatching to a smaller number of
> threads. But then you're back to the scheme I'm proposing, in essence,
> just with another layer of code (bloat) on top.
no, it's exactly what you propose, but with a standard interface
(aio_*()). That is used widely amongst databases like Oracle and Informix.
this discussion is getting pointless :( i'm just proposing that instead of
reinventing the API wheel, you should use an already existing _user API_.
So instead of slice_and_dice_*() you could actually name it aio_*(), and
there would be actually code out there that might run with your code.
[unless there is something fundamentally broken about the aio_*() _API_,
which possibility i've left open from the very beginning]
> > i was just suggesting this, nothing else. Please use an existing interface
> > (unless that interface is broken). Especially as the hard work of
> > integrating it and getting it to work has already been done ...
>
> That is what I favour: using the existing interface (poll(2) and
> pthreads) in a clever way such that it scales with many open
> connections. [...]
and how will you call this mechanizm, how will user-space programs use it?
i am _not_ proposing you should use aio_*() as an underlying interface,
please read my mails again. I'm proposing you should _name_ _your_ clever
implementation aio_*(), so that others can benefit from your clever scheme
as well. [if possible]
> The fcntl(2) driven RT signal stuff also looks good, except that it's
> non-portable.
it is an underlying _mechanizm_ to implement a cross-platform API. Think
about it, you are simply on the wrong track. This is what i say:
oracle_server.c:
cb->aio_fildes = open(...);
aio_read(cb);
...
where, aio_read() can be seemlessly implemented in several ways (with
several underlying mechanizms):
1.
the current existing pthreads based implementation
2.
RT-signals driven
3.
Richard Gooch's thread trick
do you now see my point? If yes then please go back and reread the thread
...
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu