Messages in this thread | | | Date | Fri, 26 Jun 1998 23:16:38 +0200 (MET DST) | From | MOLNAR Ingo <> | Subject | Re: Thread implementations... |
| |
On Fri, 26 Jun 1998, Richard Gooch wrote:
> > 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
| |