Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: Can a process stop with a locked inode?
Message-ID: <19416@rpp386.cactus.org>
Date: 27 Jun 91 14:02:27 GMT
References: <4200@island.COM> <1991Jun25.232436.1215039@locus.com> <1991Jun26.093356.12661@prl.dec.com>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Cheeseburger in Paradise, Le Select, St Barts., FWI
Lines: 31

In article <1991Jun26.093356.12661@prl.dec.com> boyd@prl.dec.com (Boyd Roberts) writes:
>In article <1991Jun25.232436.1215039@locus.com>, richard@locus.com (Richard M. Mathews) writes:
>> It sounds like that is what is happening.  This is possible if you ever
>> sleep at pri>PZERO while the inode is locked.
>
>This is nonsense.  When the inode is locked no process, apart
>from the one with the lock, can operate on it.  Sleeping with
>the inode locked may make things worse, but the priority is irrelevant.

No, it isn't nonsense.  The reason that a level like "PZERO" exists is
to distinguish between things that can happen real fast (short term
sleeps) versus real slow (longer term sleeps).  PINOD is as low as it
is to insure that the sleeping process 1) isn't interrupted (including
SIGSTOP or SIGTSTP) and 2) gets the CPU back.  No process should =ever=
sleep with an inode locked above PZERO for many very simple and obvious
reasons.

>Unless you're really sure about what you're doing, any kernel data you observe
>will just confuse you.  Even in a static system (a crash dump) it is often
>far from obvious what is going on.  Maybe the `problem' isn't with `cp'.

Trust me, Richard knows exactly what he is talking about.  Arguing with
him is not unlike arguing with Guy Harris or Doug Gwyn.  It gives you this
warm feeling in your stomach that is often confused with "warm fuzzies",
but which is really heartburn.  Richard's analysis is dead on.  Unless you
don't have source code access, crash is almost always your best friend.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"UNIX signals are not interrupts.  Worse, SIGCHLD/SIGCLD is not even a UNIX
 signal, it's an abomination."  -- Doug Gwyn