From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13426df10708081013t7e4d0072g21f154bca5c94336@mail.gmail.com> Date: Wed, 8 Aug 2007 10:13:41 -0700 From: "ron minnich" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Bay Area Plan 9 Users Group Meeting (August '07) In-Reply-To: <775b8d190708080426h58af05d5w58ca4aacd57efe9c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8ccc8ba40708011355v1ff80d1eu481456f50e0e05cc@mail.gmail.com> <3CEED615-AF39-4907-91EF-6F5A5FF3CC86@tinker.com> <3e1162e60708071856r3651a753k58963e306225abbd@mail.gmail.com> <775b8d190708080426h58af05d5w58ca4aacd57efe9c@mail.gmail.com> Topicbox-Message-UUID: a0116428-ead2-11e9-9d60-3106f5b1d025 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