[svlug] Re: Thread Programming and Java
tin at le.org
Thu Jun 8 10:32:57 PDT 2000
-----BEGIN PGP SIGNED MESSAGE-----
Before we continue. There seem to be another misunderstanding. My fault.
I am not defending how these other companies decided to architect their
apps. I am simply pointing out that in the _real world_ (tm) people do
things that are not always optimal. You simply can not ignore them and
tell them to go back and rewrite everything, or to throw it all away.
This is where the requirements for supporting legacy systems comes in.
Linus himself knows this and at times have bend over backward to accomodate
legacy systems. The model that OpenSource is based on work because people
use the give-n-take method.
> You're missing the point. That programming model will never be as fast as
> a non-blocking, event driven server. If you've made the decision to use N
> threads per connection, you've already thrown out performance. You're free
> to take the changes that IBM made to the Linux kernel and make this bad
> situation "suck less," but you have no right to complain about the kernel
> about performance when you picked a architecture that wasn't designed to
> go fast! (In this case, Java's networking architecture.)
Heh :-). It's not Java networking architecture that is the problem. It's
simply the lack of blocking I/O in Java that was the problem.
Let's take the case I've been using, web servers where you have a thread
handling each incoming connection. Usually you have one thread waiting on
the accept queue, wakes up to get a connection request, hands it off to a
worker thread and go back to wait.
Now please explain to me _your_ idea of how this can be architected better?
One that is "optimized" for Linux. Then perhaps you can share it with the
Apache team for v2.0.
> I'm personally not against Java, in fact, there are cases where it can
> perform better than C/C++ due to the fact that the run-time can optimize
> the generated code for the given usage pattern. But, what I am against is
> adding bloat to the kernel to better facilitate bad designs (Java's I/O
I don't see how this can be "bloat". The changes are to the way that the
kernel scheduler work. So essentially it's a change in _algorithm_. Please
explain to me this "bloat" thing. Where?
As a matter of fact, if it is possible to allow (at compile time)
the ability to chose different scheduler, that would probably solve
> Just because businesses do something with technology doesn't automatically
> make it a good technical decision. You're free to start your own version
> of the Linux kernel that is focused on making bad performance designs
> "suck less."
:-) I agree. If I have the time, I might play around with it. I've never
said that the developers "has" to do anything. Only said that Linux
"thread" model is not optimum for certain apps and that for those apps,
_I_ would suggest using another OS. That was what started this whole
thing before everyone jump on the Linux support wagon... :-)
> > If Linux wants to "grow up" and get into enterprise computing, it needs to
> > provide better support for Java and its underpinnings.
> Linux is in enterprise computing ("where have you been?").
Right along side it :-). My company probably was one of the first to use
Linux for all its servers back in 1995. Linux has grew up quite a bit since
then. For the kind of apps many companies are using Linux for now, I doubt
they would have use it back then. Certainly v1.0.x Linux would have died
under the kind of load it is being put to now.
Linux is still at the edges of enterprise computing. I do not think it
is quite there yet. It need more.... And it is issues such as what I
brought up that need to be resolved and not ignore.
I think many people missed the fact that Linux has had time to matured and
"cook". It is still going through changes, bug fixes and enhancements.
Java is going through similar growing pains. Its model is somewhat
different than Linux in that it is not OpenSource, but it does have lots
of heavy hitters and money+resources behind it.
Linux has Linus as the "keeper of the Linux way". Which was what Linux
needed. Someone to keep focus and keep it from splintering into a thousand
incompatible APIs and versions.
Java (like it or not) has Sun/Javasoft as the "keeper" to keep it from
splintering (much as Microsoft would like to do).
There are interesting and similar parallels there. They each can gain from
each other. It's better if Linux and Java work (and play) well together :-)
Because it keep the idea of "Open" going.
Internet Security and Firewall Consulting
Tin Le - tin at le.org
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the svlug