It seems that if people wanted to use generally-available TCL packages inside AOL, it'd be nice if cd worked and was per-thread. Otherwise, even if the TCL internals are fixed to lock around the temporary cd fiddling it does in realpath or wherever else, ordinary TCL packages still won't work in a threaded environment if they use cd. We've run into this problem ourselves, when we had to bring external TCL scripts into the web server, for coordination & scheduling purposes.
Jim > > On Thu, Mar 27, 2003 at 10:15:33AM +0100, Zoran Vasiljevic wrote: > > On Wednesday 26 March 2003 20:03, you wrote: > > > > > 1. Are there ANY cases where a TLS (thread local storage) cd/pwd would > > > be the WRONG thing? E.g., could we reasonally expect there to be any > > > cases where one thread A does "pwd", gets "/home/my", does "cd /foo", > > > and then thread B does "pwd" and EXPECTS to get "/foo" back as the > > > result? Any such cases in Tcl? In AOLserver? In libgcc? Anywhere > > > in any C libraries whatsoever? > > > > I did not understand. > > The scenario you've used (thread A/B) is what *is* usually happening. > > The thread B gets "/foo" and this is what is expected. > > 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. > > 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? > > > But, this is not the source of the problem. The source of the problem > > is that Tcl internal code remembers the process-wide current working > > directory in an global Tcl object and neglects to properly lock access > > to this object for ALL operations, in addition to blindly passing the > > same object to other threads. > > 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. > > Clearly from what you say it's at least a bit more complicated than > that though. I probably can't contribute any more usefully to the > discussion until/unless I go look at the Tcl core code you're talking > about... > > > We'd need to talk to the Tcl FS implementor and get him/them abandon > > the object storage in favour of simple char* or put the object > > into the TSD. > > What's the TSD? > > > Again, I'm sorry if I misunderstood your question(s). I think that > > you can't protect yourself from the effects of the [cd]. You will, > > I wasn't trying to protect myself, I was hypothesizing about possible > designs/implementations for fixing the problem in Tcl. :) > > 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. > > I've run into that before and solved it by overriding library > functions with my own mt-safe TLS versions of those functions, which > let me avoid having to try to share a single mutex across multiple > non-cooperatiung libraries. Thus I immediatly wondering about the > possibility of using TLS to solve the cd/pwd bugs you described... > > > I think it would be good to know what exact spots in Tcl might be > > potential [cd] doers. I will try to grep the code and see what > > Definitely, that would be good to know. > > -- > Andrew Piskorski <[EMAIL PROTECTED]> > http://www.piskorski.com > > > -- > 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/ > -- 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/
