On Tue, Aug 18, 2009 at 7:03 PM, Mark J. Reed<markjr...@gmail.com> wrote: > The OS-level chdir() and getcwd() are not thread-safe. The usual > advice is to ignore them completely in multithreaded programs, in > favor of absolute paths (or relative paths from a fixed location, > never calling chdir()). This is part of the a reason that Apache2 > recommends fastcgi for non-prefork MPMs (since the CGI spec requires > cgi scripts to start with getcwd() set to the directory containing > them).
I like Timothy's suggestion: do not associate $*CWD with chdir at all, but tie $*CWD in with every standard routine that makes use of the "current working directory" concept. Keep chdir around, but add a note saying that its use should be avoided in favor of assigning to $*CWD. Ditto with getcwd and reading the value of $*CWD. The only thing that gets clobbered by this is the inability to use relative paths when changing the current working directory. Personally, I have no problem with the idea that $*CWD is a magical Path that resolves itself into an absolute Path when you assign a relative Path to it (that is, $*CWD = ($path.relative ?? $*CWD ~ $path :: $path).resolvepath, or something to that effect) - and thus is always an absolute Path; but I can understand that others have a problem with this. On a similar note, I wouldn't mind a bit of magic that has $*CWD test for the existence of the new value before actually making the change, and throwing an exception if the target is not a directory; that way, you're guaranteed that $*CWD is always a valid Path. With this magic in place, I would never be tempted to use chdir or getcwd. Alternatively, $*CWD should be readonly and have a chdir method that implements the above behavior, emulating the features of the OS's chdir in a thread-safe manner. Or just warn people _not_ to alter $*CWD directly, and change chdir and getcwd so that they alter and read $*CWD appropriately by default, and only perform their OS equivalents if you explicitly ask them to. -- Jonathan "Dataweaver" Lang
