Christopher Smith wrote:
> On 31 May 2001 10:58:08 -0700, ed phillips wrote:
> > Thanks for providing this pre-session back and forth. Although I'm excited by
>
> Probably the only way I can get people to show up for 8:30am (someone at
> KeyMedia obviously doesn't like me).
>
> > the prospects and possibility of say option number 4 over the long haul, I've got
> > to be concerned as much with stability as scalability. After all,
> > I've got to serve actually existing applications in production today.
> > ;-)
>
> Understood. I expect #4 won't be a practical option for another 6
> months. The SGI KAIO patch itself is pretty stable, but the jury is
> still out on my code. ;-) Also, there are kernel developers working on
> their own kernel AIO implementation which is signal free (kills
> portability, but does avoid a ton of hassles with the JVM).
>
> > So, the green threads or the lots of boxes w/tweaking of the kernel have been the
> > options of choice for me and my colleagues. Some people claim that green threads
> > are not at all an option when scaling is your objective, so I'm
> > heartened to see that even as you are experimenting with SGI's KAIO
> > patch, you've kept green threads as an option. I assume you are going
> > to address the tradeoffs of the various options in your presentation?
>
> The green thread option depends a lot on where you need the scalability.
> As I've said before, in most cases, the scalability need is all about
> I/O performance. Thread-per-I/O has got to be the most inefficient way
> imaginable to represent I/O on a computer. Green threads (and various
> many-to-many thread implementations) get around this (at least from a
> kernel perspective). So they are most definitely a viable option.
> They do, unfortunately, come with some caveats.
>
> > I'm interested, you might have gathered, in practical, and as stable
> > as possible, options for scaling Java on Linux.
>
> I think really most people are. The thing about the Linux world is that
> progress is moving so fast that today's "unstable, untested" feature is
> tomorrows "stable, practical" feature. Heck, I've already had to change
> the slides for this presentation a few times because of progress that
> has been made since I first started putting the presentation together.
> So, I'm going to talk both about what's practical and available here and
> now, but I'm also going to talk about what the future holds. In
> particular, I think if you are starting a project now which will be
> deployed in 6+ months, you have a lot of interesting options to
> consider.
>
Thanks again, Chris. You express well the quandary, if you could call it that, of
choosing the best option when progress is moving so fast.
Ed
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
