The IO manager opens two pipes, and (at least for kqueue) another file
descriptor. The program I'm working on (a shell!) needs to control FDs 0-9
-- so if the IO manager opens these things on those FDs, my program breaks
in spectacular ways....
I notice that in a trivial program, say
main = getLine >> putStrLn
The IO manager doesn't seem to ever get initialized - if I run lsof while
that program is waiting, none of the IO manager's FDs have been opened yet.
In my program, however, it seems that the IO manager gets opened very
early: I put in a call to System.Posix.Unistd.sleep as the first action in
main, and lsof during that call shows that the IO Manager is already
initialized. Is it the calling of something in the Posix library that is
triggering an IO Manager start? Admittedly, my program links in many more
libraries than the trivial one above.
What I want to do is at the top of main, reserve the FDs by opening
something on them before IO Manager starts, and then presumably when the IO
Manager does start, its FDs will be safely out of the way.
Can anyone help me understand what triggers IO manager initialization? (the
call to GHC.Event.Manager.new)
- Mark
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
