Re: Ensuring only one copy of a perl script is running at a time

When the file is locked on Windows, you can open it ok but you get an error when you attempt to read from it.

I'm trying to think of a situation wherein that behaviour would be useful or helpful, and I'm coming up blank. Now, if you only got an error when you tried to write to the file, I can see how that could be useful, but only when you try to read? If you can't even read, what's the point in being able to open?

But if that's the way it's always been, that's the way it'll stay. ISVs will have found thousands of ways to rely on the existing behavior, even if it makes no sense, and changing it would break them all.

So you may as well join them and actually (try to) read from the file to see if it's locked or not.

Sanity? Oh, yeah, I've got all kinds of sanity. In fact, I've developed whole new kinds of sanity. You can just call me "Mister Sanity". Why, I've got so much sanity it's driving me crazy.

Comment on Re: Ensuring only one copy of a perl script is running at a time

Replies are listed 'Best First'.

Re^2: Ensuring only one copy of a perl script is running at a time
by eyepopslikeamosquito (Archbishop) on Dec 20, 2006 at 01:31 UTC

If you can't even read, what's the point in being able to open?

The main issue here seems to be mandatory versus advisory locking. Windows uses mandatory locking, while Unix uses advisory locking (by default). The Windows locking behaviour described above is actually similar to that of (SVR3/4-based) Unix systems that support mandatory locking (via the hack of turning on the file's set-group-ID bit and turning off its group-execute bit). On such Unix systems, if a file is mandatory write-locked, the open succeeds, while a non-blocking read fails with EAGAIN and a blocking read blocks until the write-lock is removed.

[reply]
[d/l]


Perl-Sensitive Sunglasses
	PerlMonks