Re: Thread implementations...
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Sat, 27 Jun 1998 10:06:23 +1000
MOLNAR Ingo writes:
>
> 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
> ...
I see your point: modify glibc 2.1 to make it scalable. What about
other OSes?
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu