From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <48099efcbb4d2fed33f6731aa0e206d9@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu,  3 Sep 2009 12:44:23 -0400
To: 9fans@9fans.net
In-Reply-To: <1251994812.16936.4807.camel@work.SFBay.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] "Blocks" in C
Topicbox-Message-UUID: 61caa8d4-ead5-11e9-9d60-3106f5b1d025

On Thu Sep  3 12:20:09 EDT 2009, rvs@sun.com wrote:
> On Thu, 2009-09-03 at 11:54 -0400, erik quanstrom wrote:
> > > Plan 9 has a lot to offer and a lot for others to learn from. Concurrency
> > > framework that could scale up to 1K [virtual]cores in an SMP
> > > configuration is not one of those features though.
> >
> > forgive the ignorance, but is there any such thing as a
> > 1k-core smp machine?
>
[...]
> True. But even for those platforms good SMP frameworks are quite
> difficult to come by. And here I do mean computation, not how
> to accommodate scalable IO.

i'll grant you this in implementation.  the pool library's lock
in effect becomes plan 9's BLK.  since the pool library is used
in the kernel and user space, a user space application gets hit
twice.  i've been doing some full-tilt boogie testing with 2x10gbe
and even with 2 cores, the BLK^wpool lock is devastating.

where do you see the theoretical limitation in plan 9?

- erik