Re: Strange behaviour of threadWaitRead when closing the file descriptor
Hi,
Einar Wolfgang Karlsen writes:
Consider the following Concurrent Haskell program where a reader
thread is forked off to wait for input over the reading end of a
pipe. The main thread attempts after a while to close this
file descriptor.
module Main (
main
) where
import Concurrent
import Posix
import PosixUtil
import GlaExts
main = do {
(r,w) - createPipe;
forkIO (reader r);
threadDelay 10;
print "closing pipes";
try (fdClose r);
try (fdClose w);
threadDelay 10;
print "main thread done";
return ()
} where reader r = do {threadWaitRead (fdToInt r); return ()}
fdToInt :: Fd - Int
fdToInt (FD# fd#) = I# fd#
try c = catch (c = return . Right ) (return . Left)
Thanks for the tip, I've added fdToInt to PosixUtil (try is provided
by IO though.)
The outcome of running this little program is that it aborts with:
ewk@hydra% test1
"closing pipes"
AwaitEvent: select failed
ewk@hydra%
Personally I would find application development much easier if (1) the
reader thread was simply garbage collected or (2) the suspended call to
threadWaitRead failed with an error fdClosed or something like that.
(2) is my personal choice since it would allow the reader thread to do
some meaningful work in response to the error, but (1) is ok as well.
However, aborting the whole program is far too extreme for my taste and
the kind of applications that I develop (Unix client-server applications).
Hmm..there's a couple of things going on here:
- The Concurrent Haskell IO implementation isn't non-blocking.
- Hence you have to drop down to the level of file descriptors
and threadWaitReadWrite to work.
We're reluctant to add support at the level of file descriptors for
what you're suggesting, instead you should be able to write:
hCreatePipe :: IO (Handle, Handle)
main = do {
(r,w) - hCreatePipe;
forkIO (reader r);
threadDelay 10;
print "closing pipes";
try (hClose r);
try (hClose w);
threadDelay 10;
print "main thread done";
return ()
} where reader r = do {hReady r; return ()}
using a non-blocking version of IO, that implicitly would deal with
the closing of handles that other threads are waiting for I/O on.
Are there cases where a Concurrent Haskell friendly implementation of
IO would fail to deliver the functionality you want?
--Sigbjorn
Re: Profiling on HP-UX broken
Sven Panne writes: Compiling with -prof doesn't work on HPs (HP-UX 10.20): -- Main.hs -- main = return () - panne@rimatara: ghc-3.01 -prof Main.hs ghc-3.01: module version changed to 1; reason: no old .hi file collect2: ld returned 1 exit status /usr/bin/ld: Internal Error 4012 (invalid subspace in symbol_value) Using GHC-2.10 gives the same error. I can't even guess what HP's linker is trying to tell me, so what's going on here? Without -prof everything is fine. Hard to tell, the HP linker is very picky about symbols being in the right subspace, so the output from the code you're profiling is tickling a problem in the mangler, I'd say. If you have an assembler dump (i.e., the output of -ddump-raw-asm and the file produced by -keep-s-file-to) at hand, I'd be happy to have a look. --Sigbjorn
Re: quotes deleted in error messages
Hi, would it be possible to send us a copy of the code that's showing this up? We're unable to reproduce this here. Thanks, --Sigbjorn Marc van Dongen= writes: Hello there, While compiling some source code of mine, containing the following lines (line numbers included): 321 322 minCycleLength :: Vertex - (MarcMap Vertex (MarcMap Vertex v)) - Maybe Int 323 minCycleLength v g 324 = mcl ws g'' 325 where ws = mapDom (rdMap g v) 326 g' = mapMap (\wrs - mapMap (\_ - Nothing) wrs) g 327 g'' = foldr (\w g' - wrMap (rdMap g' w) v (Just (w,1))) g' ws 328 mcl [] _ 329 = Nothing 330 Line 329 was the last line of the definition of minCycleLength (under construction). The following error message was returned by ghc-3.01 Search.lhs:327: Occurs check: cannot construct the infinite type: a1Lv = MarcMap a1Lt a1Lv Expected: MarcMap a1Lz (MarcMap a1Lz a1Lv) Inferred: MarcMap a1Lz a1Lv In the first argument of `MarcMap.rdMap', namely `g' In the first argument of `MarcMap.wrMap', namely `(MarcMap.rdMap g w)' It seems as if the quote symbol in the fragment (rdMap g' w) in line 327 has been omitted somehow. The two nearest occurences of the regular expression "rdMap[ ]+g[ ]+w" are more than 100 lines before and 30 lines after line 327. If needed, I can provide the source-code from which this was generated. Regards, Marc
ghc-3.01 and gcc 2.8.1
Hi, last week someone here at our department installed a new gcc. We used to have 2.7.2.x and we have now 2.8.1. Suddenly our sources we compiled with ghc-2.10, ghc-3.00-1 and ghc-3.01 crashed. OK. The old gcc can still be called as gcc.o. Exchanging gcc with gcc.o in the ghc driver fixed this problem. Fine. But ... now I tried to compile a new ghc-3.01 with the "fixed" ghc-2.10 and guess ... it crashed :-( How do I get out of this problem ? Do I have to proceed in a special way during compiling the compiler --- I already tried to ways --- or is it still not adopted to gcc 2.8.1 ? Thanks, Stefan. -- Stefan Westmeier[EMAIL PROTECTED] BISS vox humana: +(49) 421 218 4228 FB3 Uni Bremen fax machina: +(49) 421 218 3054 Stefan Westmeier [EMAIL PROTECTED] Schaphuser Str. 24vox humana: +(49) 421 424001 D-28307 Bremen fax machina: +(49) 421 424045 Germany cellular: +(49) 171 2672149
Re: ghc-3.01 and gcc 2.8.1
Stefan Westmeier writes: Hi, last week someone here at our department installed a new gcc. We used to have 2.7.2.x and we have now 2.8.1. Suddenly our sources we compiled with ghc-2.10, ghc-3.00-1 and ghc-3.01 crashed. OK. The old gcc can still be called as gcc.o. Exchanging gcc with gcc.o in the ghc driver fixed this problem. Fine. But ... now I tried to compile a new ghc-3.01 with the "fixed" ghc-2.10 and guess ... it crashed :-( That's puzzling - this should be identical to compiling with 2.7.2, no? Are you sure you're linking with 2.7.2 code and libraries? Notice that gcc is called directly in a number of places when compiling ghc from source (e.g., ghc/runtime/gmp and various bits in ghc/compiler/parser/) How do I get out of this problem ? Do I have to proceed in a special way during compiling the compiler --- I already tried to ways --- or is it still not adopted to gcc 2.8.1 ? We've not tried 2.8.1, but compiling with pre-2.8.0 releases has been seen to work OK. --Sigbjorn
