So you hoped Perl docs would say "We can guarantee that no provider of Perl will ever change the source code nor use a C library such that ..." ?
For any feature of an implementation of a programming language - and Perl's rename is not an exception -, the implementation can either guarantee a certain behaviour, or let the behaviour be undefined. I don't know whether it is, in this case, possible to guarantee atomicity for rename. Reading through the postings in this thread, some contributors seem to be sure that I can rely on atomicity for the platforms I'm running Perl one, Corion doubted that this could be guaranteed with NFS (a point where rowdog disagrees), and so on. I don't have the knowledge to jugde about the conditions, under which I can rely on rename's atomicity, but, yes, I had hoped that IF such guarantees can be done, they would be documented at least in perlport. Of course, IF such guarantees can NOT be done, I don't expect the Perl docs to point this out (this would be too much to ask), but then it would be safer not to rely on this feature and stick with my cooperative solution regarded cooperative locking.
Of course if a provider of a Perl distribution compiles Perl with a buggy compiler (say), then whatever guarantees we find in the Perl docs, they are not necessarily true anymore - the old "garbage-in, garbage-out" principle.
--
Ronald Fischer <ynnor@mm.st>
| [reply]
[d/l] |
then it would be safer not to rely on this feature and stick with my cooperative solution regarded cooperative locking
Did you try it? It is pretty easy to implement a test where you have process "A" lock until you press Enter and then see if process "B" blocks until then and then vice versa.
I don't think anybody addressed "your current solution". A couple of quick google searches indicate to me that the different things used to implement Perl's flock (usually flock or fcntl's F_GETLK on Unix and LockFileEx on Windows) won't reach across operating systems.
| [reply] |
| [reply]
[d/l] |