Re: [9fans] Awk or Limbo ?

Re: [9fans] Awk or Limbo ?

[geoff.9fans]

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.  Unix LWPs
are fighting Unix, specifically the libraries, that were designed
assuming one process (or "thread") per address space.  This is one
reason (aside from unportability across Unixes and dubious gains) that
we let Rich Salz go off and do INN; I had no desire to deal with that
mess, especially the mess 10 years ago.

However, limbo is implemented as a part of Inferno and the two are
somewhat intertwined, so running limbo programs on Plan 9 is really
running limbo programs in Inferno on Plan 9, and Inferno's interface
as a command (emu) to the surrounding Plan 9 isn't seemless, though
it's getting better.  Thus forsyth's recent comments about a native
implementation of limbo on Plan9, which would make it more appealing
for some jobs.

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.

[9fans] threads in Plan 9

[Scott Schwartz]

| 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.

Re: [9fans] Awk or Limbo ?

[Boyd Roberts]

pthreads -- awful.

i coded up the pthreads version of a hash table of linked
lists -- ghastly.

bio.c had it right.

Re: [9fans] threads in Plan 9

[Douglas A. Gwyn]

forsyth@caldo.demon.co.uk wrote:
> it is fascinating how close they skirt to undecidability.
> is that good or bad?  i can't decide.

Why would it be bad?  Any sufficiently interesting system
must have undecidable constructs.

Re: [9fans] threads in Plan 9

[Richard Miller]

> I used to have great fun with mothra when one process would crash, and
> leave the rest deadlocked or otherwise boggled.

This behaviour seems to be a consequence of the atnotify handler
in the event(2) package used by mothra.

When a note is received in the main process, the handler sends a "die" note
to all the subprocesses and returns 0 to request the default exception
action (exit or suspend).  But when a note is received in a subprocess, the
handler simply returns 1 to request continuation.  If the note occurred
during a system call (e.g. reading from the network), in most cases the
continued mothra process will detect the abnormal return and exit.  If not,
the "die" note is simply ignored and deadlock results.

I wonder whether /sys/src/libdraw/event.c:#6972,#6980 should be "return 0" ?

-- Richard

Re: [9fans] threads in Plan 9

[forsyth]

>>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.

there are a few little traps and pitfalls in limbo/inferno too.
it's tricky, because there are conflicting requirements.

recently i've had to look at XML and its near and far relations.
it is fascinating how close they skirt to undecidability.
is that good or bad?  i can't decide.

Re: [9fans] threads in Plan 9

[jmk]

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.