setCurrentDirectory and lightweight threads

Wolfgang Thaller wolfgang.thaller at
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
> abstraction.

> 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:, and 

> 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 mailing list