Re: [9fans] Bay Area Plan 9 Users Group Meeting (August '07)

["ron minnich" <rminnich@gmail.com>]

A good time was had by a few. We didn't leave until 11 pm! I showed
the lguest demo and the way that a single tcp connection had of
locking up. David Presotto spent a good hour helping us debug it and
we're pretty sure we know what's up. I continued my winning streak of
"demos that break" -- well, consistency is good I guess.  It's an
interesting problem and the debugging of it was fun, we even got to
use the google whiteboard at one point. David said he enjoyed
debugging his own TCP stack for a change. The lguest fix should be up
soon for you all to try. I'll announce it here.

Brucee talked about his 9ee stuff, which will allow you to run plan 9
apps native under different OSes. He'll have to explain to us how this
differs from p9p, because I don't think I totally got it all. It
essentially (I hope I get this right) wraps plan 9 libc calls around
native calls, and no other code changes. Did I get that close, Brucee?
It currently works on WIndows, although namespace support is not
totally there.

Thanks to David Hendriks and Google for hosting this. Both meetings
have been a real treat for me and I hope the others who attended.

I am thinking for the next meeting we could have an Omero theme.
People could bring their Omero setups and we could compare notes. It
would be interesting to see how it all works. Maybe nemo could fly
over from Spain :-)

On a more controversial note, we had a good discussion on scaling
limitations of the current system call interface and how a new type of
asynchrony might be introduced. One idea was that one could build on
the current rendezvous interface so that it could accept a closure (or
context). Then the user process would fire up a bunch of threads, most
of which would hang out in the rendezvous. For non-blocking I/O, a
process would kick off the system call, but the system call would
return immediately after queueing up the I/O and the actual return
would wake up one of the threads waiting in the rendezvous. This was
just one idea, but it's interesting. The bigger question, for me,
remains: how would we extend the system call interface to handle,
e.g., 100,000 connections to "something(s)" without losing the essence
of Plan 9? This question is not academic -- the BG/P machines are
planned to have 256K CPUs, and we plan to run on them. We could just
claim that firing up  an ioproc for each file descriptor would work,
but I've never been comfortable with that model -- for one thing, I
can tell you from experience that seeing even 20,000 procs in a ps is
fairly confusing. We could punt and just say "9p everything", but as
David pointed out, that leaves us with a fairly chaotic universe -- we
lose a lot of the ordering and such that the kernel gives us now via
the basic open/read/write/close interface.

Linux handles asynchrony now with select/poll/epoll/etc. etc. . And,
like it or not, it has demonstrated an ability to handle it well -- at
least one some worlds. Plan 9 as currently designed is fine for the
10-100 machine case; what would we do for the 10,000-1,000,000 case?

I'm tossing this little grenade out in the hopes of provoking a
discussion. References to past work would be interesting to hear.

thanks

ron