On Sun, Nov 13, 2011 at 17:33, <wagnerdm@seas.upenn.edu> wrote:
3. The failure mode described in the putSelection bug (where xmonad hard locks and must be killed outright) will *not* happen.

*Almost* certainly will not happen.  It would take something opening a bunch of windows or otherwise flooding the main input queue, *or* dmenu being programmed to do something which required a response from the window manager; both are highly unlikely, but conceivable (and the latter would require a bug on your part or an unexpected and probably unwanted change to the dmenu source).

This kind of thing really wants to be handled as a callback invoked within the handleEventHook, but that's moderately painful in this particular case (you'd need to wrap dmenu with something that set a root window property that xmonad would watch for).  I can't help but think there should be a better way, but I'm not sure there actually is.  (The event loop could be rewritten to support multiple filehandles, which would actually be good enough in this particular case.  More generally, Unix/POSIX lacks a good event-based interface which can detect non-file-like events; many things map to signals, which can be sort of handled gracefully with some hackery in C but are not handled particularly well by GHC's runtime.  And some of the things that are managed with signals in POSIX (asynchronous IO, child processes) are best characterized as hacks.)

(Aaaaaand I'm ranting now, about stuff that's currently somewhat outside what xmonad can do anything about.  Sorry.)

--
brandon s allbery                                      allbery.b@gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms