I/O in Haskell (Re: hugs => ghc) (fwd)

[Hannah Schroeter]

Hello!

Some time ago, I discovered a problem with some of GHC's extensions,
mainly executeFile. However, I don't know if that's fixed till now,
GHC5 doesn't bootstrap at all on OpenBSD/x86.

Kind regards,

Hannah.

Path: mamba.pond.sub.org!not-for-mail
From: hannah at mamba.pond.sub.org (Hannah Schroeter)
Newsgroups: comp.lang.functional
Subject: Re: I/O in Haskell (Re: hugs => ghc)
Date: 1 May 2001 09:42:15 GMT
Organization: Chaos
Lines: 44
Message-ID: <9cm0dn$fjb$1 at mamba.pond.sub.org>
References: <9ak0ss$gs at first.in-berlin.de> <9ann47$11u at first.in-berlin.de> <9bcl8i$8v at first.in-berlin.de> <slrn9dk7lv.6mp.qrczak at qrnik.zagroda>
NNTP-Posting-Host: mamba.pond.sub.org
X-Newsreader: trn 4.0-test74 (May 26, 2000)
Originator: hannah at mamba.pond.sub.org (Hannah Schroeter)
Xref: mamba.pond.sub.org comp.lang.functional:14361

Hello!

In article <slrn9dk7lv.6mp.qrczak at qrnik.zagroda>,
Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
>[...]

>Some implementations provide it as an extension. GHC has module Posix
>(available on Posix OSes only) with wrappers for features specified by
>Posix, including pipes. They are quite low level, roughly corresponding
>to the C API. An equivalent of popen can be written using following
>functions:

>    createPipe  :: IO (Fd, Fd)
>    forkProcess :: IO (Maybe ProcessID)
>    dupTo       :: Fd -> Fd -> IO ()
>    fdClose     :: Fd -> IO ()
>    fdToHandle  :: Fd -> IO Handle
>    executeFile :: FilePath                 -- program name
>                -> Bool                     -- search PATH?
>                -> [String]                 -- arguments
>                -> Maybe [(String, String)] -- environment
>                -> IO ()

There's a problem though with GHC's executeFile & co., last I tried:

GHC sets some itimer for its preemptive thread switching and
uses some signal handler which is neither SIG_DFL nor SIG_IGN.
It seems *not* to clear the itimer in executeFile. The OS resets
the signal handler to SIG_DFL on exec, but doesn't clear the itimers.
So the executed program is killed after the itimer expires once,
which usually isn't too long in the future.

Prepare for strange effects!

In a program I used execute... once, and *had* those strange effects
and didn't know where they came from, until I ktrace'd the program
and saw was happening. The only solution was to reset the itimer
for myself, creating an own setitimer binding. Surely not optimal!

>[...]

Kind regards,

Hannah.