setCurrentDirectory and lightweight threads
wolfgang.thaller at gmx.net
Sun Oct 24 12:04:30 EDT 2004
> Now, some of the most common operations used in dynamic web pages
> relate to directory listing/manipulation. I was happily thinking that
> System.Directory would provide the needed functionality. Indeed it
> does, but unfortunately setCurrentDirectory breaks the thread
> What I mean is that if one page wants to change directory using
> setCurrentDirectory, this change affects all other (lightweight)
> threads as well, which is not how "ordinary" system threads works.
AFAIK, this _is_ how "ordinary" system threads work. See, for example:
> Also it is clearly not what one would want in the kind of application
> I'm writing.
> Is this behavior of setCurrentDirectory intended? I can't see a
> situation in which you could take advantage of it, but that doesn't
> mean there can't be any. =)
> If it is not intended, is there any hope of it being "fixed"?
The behaviour is intended because it is the way the underlying
operating systems work. It's hard to work around that; while it would
be definitely possible (but tedious) to fix this for Haskell's IO
library, we'd run into serious trouble with FFI calls (if you call two
C functions from different Haskell threads, which will be the current
directory of the process while both functions execute simultaneously?)
So I fear that the only thing you can do is not to change the current
directory in multi-threaded programs.
More information about the Glasgow-haskell-users