Re: setCurrentDirectory and lightweight threads
> > 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. Hmm, I guess was confused (and is still) by the distinction between threads and processes. The following quote comes from one of your links: The current working directory is shared between all threads within the same process. Therefore, one thread using the chdir() or fchdir() functions will affect every other thread in that process. So that means you're right, and that the current directory shouldn't be tampered with in a multithreaded setting. I still don't understand *why* it is like this on the OS level, but I'm not going to opt for a change there. ;o) I guess that leaves me to implement a add layer on top of IO that can handle "directory state" of different threads. Oh well. =) Thanks for the answer, /Niklas ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: setCurrentDirectory and lightweight threads
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: http://www.uwm.edu/cgi-bin/IMT/wwwman?topic=chdir(2)&msection=3f, and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ fileio/base/setcurrentdirectory.asp 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. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
setCurrentDirectory and lightweight threads
Hello fellow Haskelleers, I've come upon a problem that sort of bites me. I'm writing a multithreaded webserver in which pages are dynamically loaded haskell applications. The main server loop listens for incoming requests and distributes these to request handlers, each running in a separate lightweight thread. 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. 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"? Regards, /Niklas ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
