From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <775b8d190601040425x1a4967f3we7fa8e7473a15f6d@mail.gmail.com> Date: Wed, 4 Jan 2006 23:25:44 +1100 From: Bruce Ellis To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] clunk clunk In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <775b8d190601031333l11782437rd6218e79f5cb3d8e@mail.gmail.com> <91a087f2f4440d8df784baf9a9abd2b6@plan9.bell-labs.com> <775b8d190601031409i76f829ebwad8ecfb4b5507d76@mail.gmail.com> <775b8d190601031445o660864c9n70425bc2ae54345@mail.gmail.com> Topicbox-Message-UUID: d1221c44-ead0-11e9-9d60-3106f5b1d025 too long for me to read. jmk has the code. On 1/4/06, Russ Cox wrote: > I apologize if I give the impression of thinking I'm always > right. I don't think I'm always right. In fact, I am > frequently wrong. > > What I do think is that in order to maintain the Plan 9 > software, it would be helpful if I understood the problem > and proposed solution before I start editing code. Too > often when I don't fully understand what's going on, bugs > end up going in with the fixes. There was a good instance > of that over the weekend -- a subtle bug introduced into > acme a few years ago (thanks to Arvindht Tamilmani for > pointing it out). > > You pointed out a scenario where two processes can deadlock. > That much I understood. There were two things I didn't > understand. > > The first was how common the problem actually was. You made > it sound like it happens all the time, and my understanding > of the problem is that it shouldn't, hence my discussion of > the usual file server conventions. You then said that > rio+plumber was an example, which would certainly be a > common case, except that as I understand the problem, > rio+plumber doesn't suffer from it. > > Other cyclic dependency loops are even more common (as I > understand them). Maybe your solution would fix those too. > > The second thing I didn't understand was what solution you > propose. Saying "go do like Inferno does" isn't really > helpful by itself. In just one or two sentences, you could > explain the solution enough to know where in the Inferno > kernel to look. > > I did look at cclose, pexit, and closefgrp in the Vita Nuova > inferno, and I didn't see anything that looked significantly > different from Plan 9. While writing this message, I > checked the archived /usr/inferno trees on emelie and they > looked the same too. I don't see anything there that would > protect against the problem you described. Perhaps I'm > looking in the wrong place, perhaps I don't understand what > the code is doing, or perhaps I don't even understand what > problem it is you were describing. > > I'm just trying to understand your suggestion. > > Thanks for your help. > Russ >