Re: Issue 317 in xmonad: Util.XSelection.putSelection repeatable hang
Comment #8 on issue 317 by ale...@feldgendler.ru: Util.XSelection.putSelection repeatable hang http://code.google.com/p/xmonad/issues/detail?id=317 The workaround prevents the freeze, but it would be nice to be able to copy text to clipboard. Why does putSelection freeze? Can't see anything suspicious by looking at its source. Nothing seems to be logged to .xsession-errors, which means that none of the print* invocations are reached. -- 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 #9 on issue 317 by ale...@feldgendler.ru: Util.XSelection.putSelection repeatable hang http://code.google.com/p/xmonad/issues/detail?id=317 gdb shows that the process hangs in XNextEvent(), which probably means it's within the forked run of processEvent. "info threads" in gdb shows there's only one OS- level thread. Here is my version of what happened: forkIO doesn't have to create an actual thread, it can be a “lightweight” thread <http://hackage.haskell.org/packages/archive/ base/3.0.3.0/doc/html/GHC-Conc.html#v%3AforkIO>. So it works as though it were a real thread as long as you don't call into libraries. Because it's not a real thread, the other thread doesn't get a chance to run while XNextEvent() is hanging. Suggested solution: use forkOS instead of forkIO, as the documentation recommends for situations when threads make blocking library calls. -- 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: Owner: --- Comment #10 on issue 317 by daniel.schoepe: Util.XSelection.putSelection repeatable hang http://code.google.com/p/xmonad/issues/detail?id=317 Using forkOS is potentially dangerous in this case, since Xlib is not reentrant. Unfortunately, there are no bindings to Xlib's locking mechanisms in the bindings at the moment, so we'll either have to add and use those or risk some other breakage or even deadlocks when using forkOS. Anyway, potential breakage still beats having a deadlock in every case. (I'm unsetting the owner of this bug since I'm not very knowlegdeable regarding these issues) -- 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 317 by ale...@feldgendler.ru: Util.XSelection.putSelection repeatable hang http://code.google.com/p/xmonad/issues/detail?id=317
Using forkOS is potentially dangerous in this case, since Xlib is not reentrant.
Even though the forked thread uses an entirely different display connection? Anyway, I tried it and it didn't help. Now I think what happens is that the eventLoop in XMonad/Prompt.hs gets the event about the new dummy window that has just appeared, and doesn't know what to do with it. -- 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 #12 on issue 317 by ale...@feldgendler.ru: Util.XSelection.putSelection repeatable hang http://code.google.com/p/xmonad/issues/detail?id=317 I tried running "sleep 5; xclock" and opening a prompt while sleeping. The xclock window didn't appear on the screen until after the prompt was dismissed, but otherwise it went OK and didn't freeze the prompt. On the other hand, during the hang (with the forkOS fix applied), I can see that the process is in a tight loop, busy reading endless events from the X socket. What could these be about? -- 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