[xmonad] exiting: asking for confirmation (or a four-key combination)
Brandon Allbery
allbery.b at gmail.com
Mon Nov 14 05:27:11 CET 2011
On Sun, Nov 13, 2011 at 17:33, <wagnerdm at 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 at gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20111113/f62e7943/attachment.htm>
More information about the xmonad
mailing list