From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <20010427192309.8495.qmail@f.bio.cse.psu.edu> To: 9fans@cse.psu.edu In-Reply-To: Message from geoff.9fans@collyer.net of "Fri, 27 Apr 2001 15:09:41 EDT." <20010427191000.3ABBA19A80@mail.cse.psu.edu> From: Scott Schwartz Subject: [9fans] threads in Plan 9 Date: Fri, 27 Apr 2001 15:23:09 -0400 Topicbox-Message-UUID: 95a3511c-eac9-11e9-9e20-41e7f4b1d025 | 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.