From mboxrd@z Thu Jan  1 00:00:00 1970
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] threads in Plan 9
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20010427200620.8B79519A0C@mail.cse.psu.edu>
Date: Fri, 27 Apr 2001 16:06:18 -0400
Topicbox-Message-UUID: 95b23cd6-eac9-11e9-9e20-41e7f4b1d025

On Fri Apr 27 15:24:32 EDT 2001, schwartz@bio.cse.psu.edu wrote:
> | For writing some applications, limbo is quite pleasant.  I've written
> | concurrent ("multithreaded") programs in limbo and felt comfortable
> | doing so, whereas using the Unix LWP (light-weight process) libraries
> | (or POSIX threads) directly has always seemed hazardous.
>
> On a slightly different topic, it has also seemed hazardous to me in
> Plan 9.  One particular thing, for example, is that there's no way to
> tell the system that a cohort of processes should be treated as such.
> I used to have great fun with mothra when one process would crash, and
> leave the rest deadlocked or otherwise boggled.  On those occasions,
> I felt like a multi-threaded application should have a kernel-enforced
> way to fail as a unit, as if there was a suicide_pact() system call,
> or something like the "reboot" device, so that of one process dies
> unexpectedly, the others do too.
>
> | libthread attempts to capture some of the benefits of limbo (notably
> | communication) in C, but I'd rather have one kind of process (not
> | processes and threads) and it feels a little like LWP libraries to me,
> | plus you don't get the concise limbo communication syntax and
> | automatic memory (de)allocation.
>
> Agreed.

There is/was a proposal on the table about a year ago for a neat way
to tidy up all this stuff. Maybe we'll get round to it once we've finished
editing all the source to get the declaration of 'main' right.