#4449: GHC 7 can't do IO when demonized
----------------------------+-----------------------------------------------
Reporter: kazu-yamamoto | Owner: adept
Type: bug | Status: new
Priority: normal | Milestone: 7.0.2
Component: Compiler | Version: 7.1
Resolution: | Keywords: forkProcess
Testcase: | Blockedby:
Difficulty: | Os: MacOS X
Blocking: | Architecture: x86
Failure: None/Unknown |
----------------------------+-----------------------------------------------
Changes (by adept):
* owner: tibbe => adept
Comment:
Ooookay. I added loads of debugIO into the "base" code, and I am getting
very strange results on FreeBSD with the code from comment #28. In
particular, I've modified `libraries/base/System/Event/Control.hs` and
made `closeControl` print out PID of the current process and the `Control`
itself.
And I am seeing this (here 3738 is the PID of the daemonized/twice-forked
process):
{{{
PID 3738. In closeControl W {controlReadFd = 4, controlWriteFd = 5,
wakeupReadFd = 6, wakeupWriteFd = 7}
PID 3738. In closeControl W {controlReadFd = 8, controlWriteFd = 9,
wakeupReadFd = 10, wakeupWriteFd = 11}
PID 3738. In closeControl W {controlReadFd = 12, controlWriteFd = 13,
wakeupReadFd = 14, wakeupWriteFd = 15}
}}}
And the way it is printed suggests that all closeControls are run at once
when innermost process terminates (way before threadDelay timeout expires,
I might add).
Now, could someone please explain to me:
1. Why all `closeControl`s are run inside the single process? I thought
that children do not inherit threads of parent - so how the Control from
parent is used in child at all?
2. Am I right in assuming that child process inherits `controlReadFd`,
`controlWriteFd`, `wakeupReadFd`, and `wakeupWriteFd` from its parent, and
this is not a desired behaviour at all?
3. Maybe we should add function like `forked` to all backends which would
be called by `forkProcess` and would do the sensible thing in restoring
"status quo" afther the fork?
Or, maybe, we should remove forkProcess at all and say that external
"daemonizing" tools should be used, if needed?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4449#comment:32>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
