+---------- On Mar 27, Andrew Piskorski said: > And if that object were TLS, per-thread, then the error could not > occur. It might cause OTHER problems, which is what my questions > above were getting at, and it might plain not be feasible to > implement. But a TLS pwd would solve the "blindly passing a > process-wide object to other threads" problem above, because it > wouldn't be process-wide anymore, it'd be per-thread.
Perhaps you do not realize that a process's current working directory is tracked by the kernel, not by the process. Tcl keeps track of its CWD for speed, but ultimately it's the kernel, not the process, that resolves relative pathnames, so it's the kernel's idea of the CWD that matters. I believe that POSIX requires that all threads in a process share a working directory. Making each thread appear to have its own working directory requires either non-standard kernel support for per-thread CWD (which Linux has, but I don't think you can get to it through the pthreads interface), or intercepting every system call that involves a pathname (open, link, symlink, unlink, rename, access, stat, lstat, chdir, chroot, chmod, chown, lchown, mknod, mkdir, rmdir, bind, connect, and probably some more that I've forgotten). You might be able to ignore some of these for AOLserver, but intercepting any of them isn't necessarily easy, and it's definitely not possible to do so portably. It still might be the best way to fix this problem, though. > What's the TSD? Thread-specific data. Same thing as TLS. > The fact that some system calls apparently change pwd and then change > it back when they complete is really obnoxious, No. Some library calls change the CWD. The only system calls that change the CWD are chdir() and fchdir(). -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
