PID lockfile

[Aahz]

In article <87zlf5qi4z.fsf at benfinney.id.au>,
Ben Finney  <ben+python at benfinney.id.au> wrote:
>aahz at pythoncraft.com (Aahz) writes:
>> In article <87iqlwvemo.fsf at benfinney.id.au>,
>> Ben Finney  <bignose+hates-spam at benfinney.id.au> wrote:
>>>
>>>In the case of the ‘lockfile’ library, Skip is aiming for a
>>>cross-platform solution, with atomic behaviour; he has implemented
>>>lock acquisition with a ‘link’ operation on Unix, and a
>>>‘mkdir’ operation on Windows.
>>>
>>>But both of those, of course, create a new file. What I want is to
>>>lock an existing file. Is ‘lockf’ particularly prone to
>>>cross-platform troubles on Unix variants? (Since the “become a
>>>daemon� pattern makes no sense on anything but Unix, I'm only
>>>concerned with PID file behaviour that works on Unix.)
>
>Hmm, looks like your client is messing up character encoding.

Yes, it does, I'm using trn3.6 from the early 90s, and trn4 has some
annoying bugs that keep me from upgrading.  Maybe one of these years I'll
switch to slrn.  (Plus I've never bothered setting up vim to handle
Unicode.  Just call me ASCII Boy.)

>> IIUC, you must use something like Skip's trick to work correctly with
>> NFS.
>
>Okay. But is that something that needs to be accommodated with,
>specifically, PID file handling? Why would a PID file ever need to be
>on NFS storage instead of local?

That's the question.  You'll probably get some complaints from people
running diskless machines, eventually, some years down the line.  At the
very least, you need to document this as a known limitation.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)"
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-3-22