On Thursday 27 March 2003 22:28, you wrote: > Yes, of course, and it can often breaks things, right? Most users of > cd/pwd seem to want to neglect the fact that the pwd state is > per-process not per-thread, so perhaps it would be simpler just to > give them that, thus side-stepping the locking issues. >
Eh, the cwd is the thing which is used by most path-related sys/lib calls to resolve the absolute path of the file. It is tracked in the kernel, not in the process, so in order to make this happen, you ought to intercept *all* of the sys/lib calls fiddling with paths. Now, Tcl with its virtual filesystem *might* achieve this, since it really isolates the upper layers from the OS-specifics. But, if you ask me, I think this is voodoo. > Therefore, assume a TLS cd/pwd implementation, where each and every > thread has it's OWN independent current working directory. Does any > code break because of this? In other words, is there any code > anywhere that both, a), properly treats pwd as per-process not > per-thread, and b), DEPENDS on the sharing of pwd across threads for > its correct behavior? In an ideal world, this is correct. It holds true until somebody gives you some extension which calls os-calls directly, not using your own notion of cwd. This is the time when things start to be very interesting (and cost lot of time/money to locate them). I know this per-thread working directory thing is very appealing but it should have been designed so by the standard and/or kernel-makers. If we try to emulate this on the very high level, we'll end up in a mess, sooner or later. > > What's the TSD? > It is the term used throughout the Tcl sources to refer to thread specific data. In AOLserver, people talk about thread local storage which is essentially the same thing. > I wasn't trying to protect myself, I was hypothesizing about possible > designs/implementations for fixing the problem in Tcl. :) > To be honest, I was also playing with this idea, but after giving it a serious thought, I've abandoned it. > The fact that some system calls apparently change pwd and then change > it back when they complete is really obnoxious, because that means > that for proper mt-safe operation, those system calls MUST expose a > mutex which any of YOUR pwd-changing code will explicitly lock and > unlock as well. This is a general obnoxious feature of multi-threaded > programming with multiple libraries - a given mutex sometimes must be > seen and used across ALL libraries, not just within one library. > Yes, some library calls, like realpath() in MacOSX (see my other posting) are doing this. They call chdir/fchdir syscalls without you knowing this possibly interacting with your own code in a different thread. This has driven me nuts for couple of days while porting our app to Darwin. Yet, there is no word about that in the manpage! I think this is one area where standard-makers must do some more work. The fact as it is now, I'm grepping thru all code, looking for obvious calls that might change cwd (chdir/fchdir). This covers most of the cases. But, there are hidden ones, and you just can't fight them back until they show they ugly head. I think I will discuss this issue with some Tcl people and try to produce a list of Tcl functions which might directly or indirectly change your working directory. Funny think about the MacOSX: even the innocent [pwd] changed the current dir! This is really crazy! Cheers, Zoran -- 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/
