On Thu, Jul 31, 2008 at 5:53 AM, Philippe Anel <[EMAIL PROTECTED]> wrote:
> Can you tell us why some things are impossible to scale with 5000 posix > threads (and easy to scale with 5000 plan 9 style threads) ? > Is this specific to posix or linux ? Or maybe you will write a paper on > this ? > > Phil; I think it's because plan 9 style threads are more like coroutines, and don't initiate a new kernel-schedulable process. If you use libthread from plan 9 port on a unix deployed system the threadcreate function doesn't make a pthread. proccreate, on the other hand, does. (on the platforms I've used). As a result you get no chance at parallelism with threadcreate, which uses more compute resources to schedule, and proccreate "might" cause two threads to run in parallel, if the code is arranged such that the two libthread processes can run independently or at least overlapping. This duality is one of the reasons I find libthread interesting in general, even outside of Plan 9. I've been writing a lot of Erlang code lately, and I keep thinking about, but not having too much time to do much about, wanting to have a runtime for the libthread "threads" that could auto-schedule them to libthread "procs", in much the same way Haskell "sparks" may end up real threads, or Erlang processes, might run in parallel. Dave > > > ----- Original Message ----- From: "ron minnich" <[EMAIL PROTECTED]> > To: "Fans of the OS Plan 9 from Bell Labs" <[email protected]> > Sent: Thursday, July 31, 2008 4:23 AM > Subject: Re: [9fans] Plan 9 on Blue Gene > > > > On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach <[EMAIL PROTECTED]> >> wrote: >> >> Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be >>> worth a ton to me in some situations. >>> Concurrent programming for the win? >>> >> >> probably not for this community. When we had plan9port in xcpu we got >> nothing but complaints. This in spite of the fact that some things are >> impossible to scale with 5000 posix threads, and easy to scale with >> 5000 plan 9 style threads. >> >> ron >> >> >> > >
