Comment #4 on issue 573 by gwe...@gmail.com: XMonad.Util.XSelection.getSelection leaks a handle to the X server http://code.google.com/p/xmonad/issues/detail?id=573 So could we do that as: hunk ./XMonad/Util/XSelection.hs 66 - if ev_event_type ev == selectionNotify - then do res <- getWindowProperty8 dpy clp win - return $ decode . map fromIntegral . fromMaybe [] $ res - else destroyWindow dpy win >> return "" + result <- if ev_event_type ev == selectionNotify + then do res <- getWindowProperty8 dpy clp win + return $ decode . map fromIntegral . fromMaybe [] $ res + else destroyWindow dpy win >> return "" + closeDisplay dpy + return result ? Compiles, anyway. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

Comment #6 on issue 573 by allber...@gmail.com: XMonad.Util.XSelection.getSelection leaks a handle to the X server http://code.google.com/p/xmonad/issues/detail?id=573 This transcript from IRC explains what's going on here and why this (and the infamous putSelection previously eliminated from the module) cannot work as written. [31 21:34] * geekosaur also finds another potential putSelection-style deadlock in the code... furrfu [31 21:34] <geekosaur> XSelection needs to be taken out and shot. but one done correctly will not in any way be compatible and will annoy users [31 21:35] <geekosaur> because it needs to use callbacks [31 21:35] <geekosaur> people think selection manipulation is something that can trivially be done synchronously [31 21:35] <geekosaur> X11 disagrees and will happily deadlock you [31 21:36] <pharaun> ouch [31 21:37] <kaol> XSelections are held by an X client until someone comes and asks them what it is. [31 21:37] <geekosaur> sure, then there's a negotiation [31 21:38] <geekosaur> so, one (uncommon but possible) way to deadlock xmonad in the current getSelection is to kill the client holding the selection before it can receive or respond to the SelectionRequest event [31 21:38] <geekosaur> getSelection will loop forever looking for an event that will never arrive [31 21:39] <geekosaur> a way you could trigger this practically is by trying to use it when the selection happens to be held by something which is advertising a non-text selection [31 21:41] <geekosaur> if it has a bug where receiving a request for UTF8_STRING causes it to crash (either because it's not expecting it / naïvely assumes it will always receive an appropriate request, or because it crashes trying to come up with a suitable text response) [31 21:50] <pharaun> i *noticed* the xselection being held by a xclient thing [31 21:50] <pharaun> i used to select then close and try to paste and was like ... its not working?? [31 21:51] <kaol> Yes. That's one effect of it. [31 21:51] <pharaun> well that explains why [31 21:51] <geekosaur> yes, the selection isn't a pasteboard/container, it's just an advertisement [31 21:51] <pharaun> yeah [31 21:52] <pharaun> i'm not the most familiar with x11 protocol so didn't know that but after noticing that effect i adjusted my flow slightly and never had a issue since [31 21:52] <geekosaur> clients respond to the ad by sending a selection request saying "I'd like your selection in one of these formats" and then they haggle until they either settle on a mutually acceptable format or abort by not responding [31 21:54] <geekosaur> nobody actually uses it this way, which is why you get copy image location / copy image in a browser instead of just a copy image and if you then paste it as a string you get the location [31 21:54] <geekosaur> people don't think the way X11 selections were designed [31 21:55] <pharaun> that seems unfortunate [31 21:55] <pharaun> because it seems like it would be neat esp being able to haggle which format they want [31 21:57] <geekosaur> the envisioned behavior was that when you go to paste it, it can display a menu of various formats you might want, including multiple string formats (so, for an HTML editor, you might want to pick between an image URL vs. a prebuilt <img> link) [31 21:57] <geekosaur> ideas that never happened [31 21:57] <geekosaur> (like Windows' "Paste Special" only done right) [31 22:07] <pharaun> oh yeah windows paste special, i remember that [31 22:07] <pharaun> i wonder how come it never happened? [31 22:07] <pharaun> too complicated? [31 22:08] <geekosaur> like I said, nobody understood it [31 22:08] <pharaun> :\ [31 22:09] <geekosaur> people write code like XMonad.Util.XSelection that completely do not understand how selections work and therefore can't imagine those possibilities [31 22:09] <pharaun> :\ [31 22:10] <geekosaur> people think of selections as mailboxes, not as haggling. the thing in the mailbox can't change form for whatever picks it up, it's fixed when it's mailed [31 22:11] <pharaun> ahhh [31 22:11] <pharaun> looking at that code now, its yeah ok [31 22:12] <geekosaur> I don't think it's too complicated really, it's just that nobody thinks about it right, they expect mailboxes so that's what they end up with [31 22:13] <pharaun> heh and if everyone is going to think like that, you're not going to be able to do the haggling anyway [31 22:13] <geekosaur> which might be a documentation problem, maybe on the part of the toolkit folks --- I have not looked at how gtk handles selections but I bet it uses that mailbox model [31 22:13] <pharaun> ahh [31 22:14] <geekosaur> especially since CLIPBOARD can't seem to decide which it is --- it does some things like a mailbox and some like haggling [31 22:14] <geekosaur> whereas PRIMARY is a haggling model -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings