Re: Issue 91 in xmonad: DynamicLog causes xmonad to hang when the output pipe is full
Comment #8 on issue 91 by dnietoc: DynamicLog causes xmonad to hang when
the output pipe is full
http://code.google.com/p/xmonad/issues/detail?id=91
From "The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition", execve:
Signals set to the default action (SIG_DFL) in the calling process image
shall be
set to the default action in the new process image. Except for SIGCHLD,
signals set
to be ignored (SIG_IGN) by the calling process image shall be set to be
ignored by
the new process image. Signals set to be caught by the calling process
image shall
be set to the default action in the new process image (see
Ignored signals are inherited by child processes which may break if they rely on
Comment #9 on issue 91 by SpencerJanssen: DynamicLog causes xmonad to hang when the output pipe is full http://code.google.com/p/xmonad/issues/detail?id=91 the default behaiviour of a SIGPIPE signal. Has this caused problems for you? I don't believe we've had any reports of issues with inheriting SIGPIPE. Regardless, I've pushed a patch to darcs xmonad that resets this signal in processes fork()ed by xmonad. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Comment #10 on issue 91 by dnietoc: DynamicLog causes xmonad to hang when the output pipe is full http://code.google.com/p/xmonad/issues/detail?id=91 Yes, I have some problems because of an application which is not checking for errors returned by printf. I'm using a bash script to process the output of this app and feed xmobar with the result. It looks like: app | ( while read;do # blah echo blah || exit # output is connected to a pipe read by xmobar. exit on error done ) When xmobar is killed the pipeline is broken and the script should end. The right side of the pipe handles the error when echoing and finnishes correctly. (I tried with trap but it didn't work) However, app keeps running forever as it cannot handle EPIPE errors. I've been further investigating the issue and this is not only caused by xmonad's handlers but also by ghc itself. See: http://hackage.haskell.org/trac/ghc/ticket/1619 I'm no sure what has to be done here. I think I should fix the application either by reenabling SIGPIPE or properly handling EPIPE errors. But this is specially problematic for shell scripts because when a non-interactive shell is started while some signals have SIG_IGN as its handler the script cannot set traps on those signals. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Comment #11 on issue 91 by elias.kunnas: DynamicLog causes xmonad to hang when the output pipe is full http://code.google.com/p/xmonad/issues/detail?id=91 I've been researching this bug for a long-ish time. It might be that the way EPIPE is handled by xmonad or GHC has some relevance to this, but it's very likely not the primary cause. I've been rather exhaustively trying different combinations of EPIPE handlers in xmonad (including not handling it at all, setting arbitrary handlers and using the default handler), and nothing so far has affected the buggy behaviour that I'm able to reproduce ~30% of the time with the config on comment 5. One fairly sure sign that GHC itself has much to do with this, although I haven't been able to replicate the behaviour outside xmonad, is that even setting a timeout to each log write will still cause xmonad to hang. I mentioned this in #haskell@freenode and it turns out people have experienced similar issues with fdRead (assuming pipe writes are ultimately calling that, though I haven't been able to follow the code to this point). In http://upcycle.it/~blackh,/Server.hs, the issue with fdRead was fixed apparently by adapting the code from ghc-6.12. Since this fixes the issue with fdRead, it seems it may well be the case that just using GHC-6.12 would fix pipe writes as well (so presumably fdWrite). It seems the reason for this is that up to GHC-6.10, fdRead (and presumably fdWrite? Haven't been able to verify this yet) were implemented using unsafe ccalls whereas they now use safe ones. Following the discussion on #haskell, the unsafe ccalls might then starve the threads of their process, which would be consistent with seeing 'timeout' not halting the IO writes. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
participants (1)
-
codesite-noreply＠google.com