too long for me to read.  jmk has the code.

On 1/4/06, Russ Cox <[EMAIL PROTECTED]> 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
>

Reply via email to