Re: Issue 197 in xmonad: Blocking on nextEvent stops other threads from running
Comment #4 on issue 197 by byorgey: Blocking on nextEvent stops other threads from running http://code.google.com/p/xmonad/issues/detail?id=197 What's the status of this ticket? Is this a WontFix? Or is there something that could be improved here? -- 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 #5 on issue 197 by amdragon: Blocking on nextEvent stops other threads from running http://code.google.com/p/xmonad/issues/detail?id=197 I would love to see this addressed. In order to do simple things in the background like updating the clock in my dzen, I broke down and forked completely separate xmonad processes and used pipes to coordinate. A very 90's solution that is downright nightmarish next to the power and simplicity of concurrent Haskell. Is there a good reason not to simply add -threaded to xmonad.cabal? -- 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 #6 on issue 197 by vogt.adam: Blocking on nextEvent stops other threads from running http://code.google.com/p/xmonad/issues/detail?id=197 xlib isn't threadsafe, so supposedly you can crash X (or at least xmonad) if you manage to do calls to X from more than one thread. I think sjanssen's idea (something started?) of caching common X11 calls might be of use here: have a single thread multiplex all X calls from various threads. Are there any reasons that design wouldn't permit a reasonably safe -threaded (other than having to somehow prohibit access to, or change the X11 binding)? Perhaps a better option is if somebody put the effort into porting xmonad to xhb instead? -- 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
Updates: Status: WontFix Comment #7 on issue 197 by SpencerJanssen: Blocking on nextEvent stops other threads from running http://code.google.com/p/xmonad/issues/detail?id=197 Reasons we'd rather not build with -threaded: - it isn't necessarily supported on all platforms (though the important ones, like x86 Linux do support it) - it uses more CPU in idle states, this will drain your laptop's battery more quickly - multi-threaded xlib is a nightmare In regards to amdragon's situation, I think it is a violation of separation of concerns to output non-xmonad status from xmonad. Rather, it is better to run the clock separately and use some sort of multi-plexer to put the two streams together. See xmobar for a nice application of Haskell's concurrency to combine streams from disparate asynchronous sources.
Perhaps a better option is if somebody put the effort into porting xmonad to xhb instead?
This may not be feasible. At the very least it would be quite a bit of work and would require removing some features (xft, for example) -- 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 #8 on issue 197 by nwfilardo: Blocking on nextEvent stops other threads from running http://code.google.com/p/xmonad/issues/detail?id=197 As a counterpoint, if xmonad is spawning processes and wanting to respond to their deaths, there's not really a more convenient answer than forkOS getProcessStatus . The "catch SIGCHLD and dispatch" answer is inconvenient since the signals take place in the IO monad, not the X monad. Thoughts?
participants (1)
-
codesite-noreply＠google.com