October 2004 - Glasgow-haskell-users

Process library and signals
by Glynn Clements 26 Oct '04

26 Oct '04

Having looked at the latest version of the Process library, it appears that my earlier comments about signal handling may have been misinterpreted. First, my comments regarding the handling of SIGINT/SIGQUIT were specific to system(). The C system() function ignores these signals in the parent while the child is executing. However, this doesn't necessarily apply to other functions; e.g. popen() doesn't ignore these signals, and runProcess probably shouldn't either. With system(), the parent blocks until the child is finished, so if the user presses Ctrl-C to kill the "currently executing" process, they probably want to kill the child. If the parent wants to die on Ctrl-C, it can use WIFSIGNALED/WTERMSIG to determine that the child was killed and terminate itself. OTOH, with popen(), the parent continues to run alongside the child, with the child behaving as a "slave", so the parent will normally want to control the signal handling. Ideally, system() equivalents (e.g. system, rawSystem) would ignore the signals in the parent, popen() equivalents (e.g. runInteractiveProcess) wouldn't, and lower-level functions (e.g. runProcess) would give you a choice. Unfortunately, there is an inherent conflict between portability and generality, as the Unix and Windows interfaces are substantially different. Unix has separate fork/exec primitives, with the option to execute arbitrary code between the two, whilst Windows has a single primitive with a fixed set of options. Essentially, I'm not sure that a Windows-compatible runProcess would be sufficiently general to accurately implement both system() and popen() equivalents on Unix. Either system/rawSystem should be implemented using lower-level functions (i.e. not runProcess) or runProcess needs an additional option to control the handling of signals in the child. Also, my comment regarding the signals being "reset" in the child was inaccurate. system() doesn't reset them in the sense of SIG_DFL. It sets them to SIG_IGN before the fork(), recording their previous handlers. After the fork, it resets them in the child to the values they had upon entry to the system() function (i.e. to the values they had before they were ignored). The effect is as if they had been set to SIG_IGN in the parent after the fork(), but without the potential race condition. Thus, if they were originally ignored in the parent before system() was entered, they will be ignored in the child. If they were at their defaults (SIG_DFL) before system() was entered, they will be so in the child. If they had been set to specific handlers, system() will restore those handlers in the child, but then execve() will reset them to SIG_DFL, as the handler functions won't exist after the execve(). -- Glynn Clements <glynn(a)gclements.plus.com>

1 0

runInteractiveProcess is broken
by Peter Simons 26 Oct '04

26 Oct '04

Neither of these functions returns the return code of the external process as promised: import System.IO hiding ( catch, try ) import System.Process import Control.Concurrent sleep :: Int -> IO () sleep n = threadDelay (abs(n) * 1000000) test1 :: IO () test1 = do (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] Nothing Nothing sleep 5 rc <- waitForProcess pid print rc -- *Main> test1 -- *** Exception: waitForProcess: does not exist (No child processes) test2 :: IO () test2 = do (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] Nothing Nothing sleep 5 rc <- getProcessExitCode pid print rc -- *Main> test2 -- Nothing I'm using the ghc from CVS-HEAD on Linux/x86. Peter

1 1

Dynamic Source Loading
by S. Alexander Jacobson 26 Oct '04

26 Oct '04

I am writing a web application server in Haskell. I would like to be able to modify the app on the fly. Simplyfing the app server, it would look like this: appServer appMVar reqChan state = do req <- readChan reqChan app <- readMVar appMVar (state',resp) <- return $ app state req forkIO $ doResp req resp appServer appMVar reqChan state' The app would get loaded as follows: updateApp writeLog appMVar moduleName fnName = do mbApp <- (getApp >>= Just) `catch` (\err -> writeLog err >> return Nothing) maybe (return ()) (overWriteMVar appMVar) mbApp threadDelay 1000 updateApp appMVar moduleName fnName where getApp = ghci_load_module moduleName >>= flip ghci_getName fnName overWriteMVar mvar val = if isEmptyMVar appMVar then putMVar appMVar app else swapMVar appMVar app {-- Is there a way to overwrite an MVar without risking blocking by another thread filling it before the putMVar? Note it would be really nice if: * ghci_load_module would use an already cached module if the underlying source file has not changed (and therefore cost little performance-wise). * the returned code would be compiled with lots of optimization, etc. * Bonus: it would verify that the loaded function is type consistent with channel but tolerate bigger data types so that if the prior app assumed state was data State = Foo | Bar It would not be an error if the new app handled a state that looked like: data State = Foo | Bar | Baz The result would be a haskell server where all the haskell source acts like asp, jsp, php pages, but its all type safe and you don't have to define a standard page type as in HSP. I am aware that there is a DynamicLoader project: http://www.dtek.chalmers.se/~d00ram/dynamic/ That lets you load "object files." But I would really like something that loads source files instead.... Is this possible? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

4 3

GHC version 6.2.2 on MacOS X via darwinports
by Gregory Wright 26 Oct '04

26 Oct '04

Hi, GHC-6.2.2 can now be built from source on Mac OS X using the darwinports systems with the default gcc. Previously, gcc-3.1 was required. Now gcc-3.3 is used when building on Panther (10.3.x) and gcc-3.1 is only required for builds on Jaguar (10.2.y). This should make life simpler for users of Panther and may even work for people with prerelease versions of Tiger. Thanks to Wolfgang Thaller for making the Mac OS X port of ghc-6.2.2 build with the default compiler, and to John Peterson (haskell.org) and Felix Kronlage (opendarwin.org) for help with hosting the new bootstrap compiler. Best Wishes, Greg Gregory Wright Antiope Associates LLC gwright(a)antiope.com

1 0

RE: Are handles closed automatically when they fall out of scope?
by Simon Marlow 25 Oct '04

25 Oct '04

On 25 October 2004 14:24, John Goerzen wrote: > On 2004-10-25, Simon Marlow <simonmar(a)microsoft.com> wrote: >> On 22 October 2004 21:58, Peter Simons wrote: >> >> On 24 October 2004 23:37, John Goerzen wrote: >> >>> * What happens when one Handle corresponding to a socket is closed, >>> but another isn't? >> >> You shouldn't have two Handles on the same socket. This is an >> unchecked error. > > This does seem useful, though. I am actually doing this in my code > and it works. One Handle is opened ReadOnly, the other WriteOnly. > That way, I can use hGetContents on the reading side in my network > code. > > If I tried that with a single Handle opened ReadWrite, then I'd get > errors about it being closed whenever I'd try to write out some data. > > I wasn't able to find any other good way around it. Hmmm, you should still be able to *write* to a socket handle that has had hGetContents applied to it. In GHC, a ReadWrite handle to a socket basically consists of a wrapper around two independent Handles, one for read and one for write, each with its own buffer. ... I just tested it with 6.2.2, and indeed it does work as I expected. But perhaps there's a bug lurking somewhere? If you do socketToHandle twice, then the danger is that one of the Handles will be finalized and close the FD before the other Handle has finished with it. In 6.4 you'll be able to use hDuplicate for this, BTW. Cheers, Simon

4 4

RE: Are handles closed automatically when they fall out of scope?
by Simon Marlow 25 Oct '04

25 Oct '04

On 22 October 2004 21:58, Peter Simons wrote: > I know it's a rather mundane question, but I couldn't find > an answer to it! > > So what does happen when I forget to hClose a Handle? Will > the garbage collector do that for me? Or not? Yes, a Handle will be automatically closed sometime after it becomes unreferenced. However, the party line is "don't rely on this behaviour", because it is inherently unpredictable, and if you get it wrong you can end up running out of file descriptors. hClose explicitly when you can. > And more specifically, what about the handles > runInteractiveProcess returns? Do I have to close the > "stdin" Handle? All of them? What happens when I use > terminateProcess? Do I have to hClose them nonetheless? The stdin handle is attached to a pipe, and you get the behaviour you expect when you close the write end of a pipe: if a process tries to read the other end of the pipe, it will get EOF. After terminateProcess, if you write to the stdin handle, you're likely to get SIGPIPE on Unix. (BTW, I assume you have a good reason for wanting to call terminateProcess). > And while I am at it: How about Socket? Do I have to sClose > a socket I obtained from listenOn or accept? A Socket isn't finalized automatically (that is, you need explicit sClose). However, if you use socketToHandle, then the Handle will be finalized, and hence the socket closed, when it becomes unreachable. On 24 October 2004 23:37, John Goerzen wrote: > * What happens when one Handle corresponding to a socket is closed, > but another isn't? You shouldn't have two Handles on the same socket. This is an unchecked error. > * What happens when one gets GC'd but another doesn't? See above. Cheers, Simon

3 2

RE: Change in ghc-6.2.2 distribution files
by Simon Marlow 25 Oct '04

25 Oct '04

Sorry I should have broadcast a message about this; I mentioned it to the *BSD guys because I knew they'd be affected, but forgot about darwinports. Sorry about that. Cheers, Simon On 23 October 2004 20:27, Gregory Wright wrote: > Hi Sven, > > Yes, that would be it. The change is harmless enough. > > Thanks for the pointer to the message. > > Greg > > On Oct 23, 2004, at 3:01 PM, Sven Panne wrote: > >> Gregory Wright wrote: >>> Did the file ghc-6.2.2.tar.bz2 get changed without the version >>> number being changed? The md5 sum of the files has changed, >>> breaking the darwinports and presumably the *BSD ports builds as >>> well. >>> I didn't see any notice to the list, so I'm not sure if the change >>> is intentional, or if the wrong file is being distributed. >> >> Hmmm, I guess it's this: >> >> http://www.haskell.org//pipermail/cvs-ghc/2004-October/022173.html >> >> Cheers, >> S. >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Mutable hash?
by Simon Marlow 25 Oct '04

25 Oct '04

On 23 October 2004 19:25, Lauri Alanko wrote: > On Thu, Oct 21, 2004 at 09:17:20AM -0400, Robert Dockins wrote: >> There is a hashtable in the IO monad: >> >> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.HashTabl e.html > > Why is it in IO instead of the more general ST? IMHO _all_ mutable > data structures should be written for ST (or a generalization > thereof), since one can always use stToIO if operation in the IO > monad is really required. Because I'm lazy, and I don't use ST very often. Patches are welcome, as usual :-) Cheers, Simon

1 0

Are handles closed automatically when they fall out of scope?
by Peter Simons 24 Oct '04

24 Oct '04

I know it's a rather mundane question, but I couldn't find an answer to it! So what does happen when I forget to hClose a Handle? Will the garbage collector do that for me? Or not? And more specifically, what about the handles runInteractiveProcess returns? Do I have to close the "stdin" Handle? All of them? What happens when I use terminateProcess? Do I have to hClose them nonetheless? And while I am at it: How about Socket? Do I have to sClose a socket I obtained from listenOn or accept? Any definite answers would be highly appreciated. Peter

2 1

setCurrentDirectory and lightweight threads
by Niklas Broberg 24 Oct '04

24 Oct '04

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

2 2