Strange behavior while piping process stdout

Learn
#21

Next questions:

  • Is runBuild being used in a threaded context?
  • If so, what happens if that context is “unthreaded” ?
#22

If by threaded context you mean with -threaded, yes I am using threaded context. Gtk hangs indefinitely out of such threaded context. Sorry if I misunderstood you.
I removed "-with-rtsopts=-N" from ghc-options and the problem still persists.

#23

No, I should have realised the question was too vague - by “threaded context” I was attempting to suggest that runBuild was being used inside another call (or calls) to either forkIO, forkOS, etc and that could be removed temporarily. If that isn’t the case (or isn’t possible)…this bug-hunt gets more complicated.

Just look through your own code and temporarily deactivate all uses of forkIO, forkOS etc - all going well, you’ll end up with runBuild being called in the same thread used by your main definition. Also enable -threaded and -with-rtsopts=-Nx, with x being the absolute minimum thread-count needed for your program to run.

#24

I am afraid I cannot change the “threaded context”. runBuild action was called from a gtk’s signal handler, and that is likely other thread than main.

-with-rtsopts=-N1 does not change anything, it is still waitForProcess: does not exist (No child processes).

Now I have a wild guess that gtk signal handler might be messing things up, no idea how to debug that. Somehow, nearly identical code works well when gtk is not involved.

Especially gtk from gi-gtk binding is weird, docs say that threadsAddIdle will run the callback at Gtk’s main thread yet

-- Gtk.uiSingleRun task = void $ Gdk.threadsAddIdle PRIORITY_DEFAULT_IDLE (False <$ task)
      Gtk.uiSingleRun $ do
        tid <- myThreadId
        putStrLn ("Gtk UI task thread id: " ++ show tid)
      Gtk.uiSingleRun $ do
        tid <- myThreadId
        putStrLn ("Gtk UI task thread id 2: " ++ show tid)

gives different thread ids. (Guess this could be from C calling haskell code)

#25

I am afraid I cannot change the “threaded context”. runBuild action was called from a gtk’s signal handler, and that is likely other thread than main.

…just make sure your code isn’t using any fork-ing facilities before going any further.

[…] docs say that threadsAddIdle will run the callback at Gtk’s main thread yet [sample code] gives different thread ids. (Guess this could be from C calling Haskell code).

It looks like you found a bug (but maybe not the bug) - either way, write up minimal programs which reproduce them and attach them to new bug reports for the gi-gtk devs to look at. But do a quick search through the existing bug-reports first (particularly for the “discrepancy-in-documentation” issue)…

2 Likes
#26

Thank you, removing some fork here and there removed the issue - which in turn helped me pinpoint the problem. It turns out, I was installing some signal handlers without knowing what I was doing. One of the signals were SIGCHLD, which was clearly interfering with child processes.

2 Likes