Re: [9fans] threads in Plan 9

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

[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

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

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