On Wed, Mar 26, 2003 at 07:19:08PM +0100, Zoran Vasiljevic wrote: > > Zoran Vasiljevic wrote:
> > >Well, the problem starts displaying itself if you ever change > > >the current directory of the process *after* the Tcl has been > > >initialized. You need not do [cd] explicitly; some internal > > >Tcl code does that on your behalf as well. > You can't just avoid it. Tcl uses [cd] in some places internaly > when doing recursive directory deletions and such. Some other > code (not yours) might also do this, to. For example, to resolve > the relative filepath. List of possible hidden uses is long. > The problem with the described bug is that it also corrupts > memory which is far more dangerous. Ah, wrong OS paths are What if, in an ideal world, all uses of "cd" should be made transparently mt-safe by making all tracking of pwd (current working directory) state use thread local storage rather than a process-wide environment variable. I have not looked at the sources to see how feasible or unfeasable this would be, but, questions: 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? 2. At what level would this hypothetical TLS cd/pwd implementation need to be inserted? Are there OS-provided library functions that themselves use cd/pwd, and would thus need to be overriden or otherwise worked around? Or do Tcl and AOLserver have their own entry points to all C function calls using cd/pwd, and we could implement the TLS stuff there? -- 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/
