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.
In reply to Re^8: locking over the network (guarantee)
by rovf
in thread locking over the network
by rovf
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |