dons:

dbenbenn:

...

Tue Oct 23 18:13:48 PDT 2007 David Benbennick * zombie_children

My .xinitrc file looks like this:

xterm & firefox & exec xmonad

The result is that when xmonad starts, it has two child processes that it didn't create. When I quit either process, the process remains forever as a zombie, because xmonad never waits on children.

My previous window manager (Window Maker) didn't suffer from this issue.

Here's a pretty simple change that makes xmonad wait on children in its main loop. We can also change spawn to only create one process instead of two, and keep spawned processes as children.

So there's a portability problem, getAnyProcessStatus calls getGroupProcessStatus, which fails on OpenBSD for some reason. We can't apply this as is, at least, since it breaks xmonad on that platform (possibly others too, I guess).

This is probably the fault of the unix System.Process binding.

Ah, the issue is this uncaught exception is thrown Prelude System.Posix.Process> getAnyProcessStatus False False *** Exception: getGroupProcessStatus: does not exist (No child processes) Which is not handled at any level. At a minimum you'd need to catch and ignore this exception in the main loop. -- Don

dbenbenn:

On 10/24/07, Don Stewart wrote:

...

Also, I'd like to know what impact, if any, waiting before every X event has.

I haven't noticed any impact on my Linux box. I assume that the wait() system call is implemented efficiently.

Though now that I think about it, it should be better to just set SIGCHLD to SIG_IGN. Perhaps that would work on BSD too? I'll send another patch ...

Strangely, getGroupProcessStatus is implemented as: getGroupProcessStatus :: Bool -> Bool -> ProcessGroupID -> IO (Maybe (ProcessID, ProcessStatus)) getGroupProcessStatus block stopped pgid = alloca $ \wstatp -> do pid <- throwErrnoIfMinus1Retry "getGroupProcessStatus" (c_waitpid (-pgid) wstatp (waitOptions block stopped)) case pid of 0 -> return Nothing _ -> do ps <- decipherWaitStatus wstatp return (Just (pid, ps)) so we get Just/Nothing distinction, *and* a possible exception that needs to be handles. How un-Haskelly. -- Don