I apologize. I hadn't meant to send my reply off to the list as a whole.
On Fri, 21 Jan 2000, David Schwartz wrote:
> > On Fri, 21 Jan 2000, David Schwartz wrote:
> >
> > > Ahh, a Java programmer, that explains it.
> >
> > So what's your experience?
> Absolutely. I've developed software for everything from embedded medical
> devices to clusters of servers managing tens of thousands of clients.
>
> Yes. I've ported enterprise code to Solaris, Irix, and Digital UNIX.
OK. For a second there it sounded like you were blowing me off with a
"real-programmer" attitude. Thus my hot response. My apologies.
>
> System threads are only needed for a very small number of things:
>
[snip]
> 2) One thread for each I/O operation you want to 'pend' that can't be done
> in a non-blocking fashion. (Network I/O doesn't count, disk I/O does.)
>
I comment that databases hit the disk a lot. Database code also tends to
page fault on data a lot, as it's jumping all over the place.
What most commercial databases (Oracle, Sybase, etc) do is exactly what
you're describing, tho- basically write their own OS, including scheduler,
to layer on top of the OS. This was the whole idea of RawIron a couple of
years back- Oracle basically went "hey, we already have basically a full
OS in our database (including device drivers and memory management)
already- what the heck do we need Solaris for?"
On the other hand, forcing each application to write it's own minature OS
(I/O interface library, scheduling algorithm, etc) strikes me as being a
bad idea. If the OS has good scheduling, the _only_ advantage user level
threads would have over kernel level threads would be fewer task switchs-
the advantage would be far simpler code in the applications, and less
duplication (and fewer wheels being reinvented badly). Oracle can afford
to write it's own OS- can MySQL?
Brian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:26 EST