Quoting Brandon Allbery :

Meh, right problem, wrong specifics. xmonad's main loop isn't running, so the problem manifests when another program opens a non-override_redirect window.

- the program may block waiting on xmonad to respond to ConfigureRequest-s, while xmonad is blocked on its output;

- a badly behaved program may map its window anyway, and you won't be able to do anything about it if it pops over the dmenu.

(I am a little surprised *dmenu* doesn't trigger #1, which makes me think it's either using override_redirect or it's case #2.)

I'm an X novice, so you'll have to spell out the conclusion a little more explicitly for me. Does this mean that spawning *some* program might cause problems, but dmenu happens not to? Or does it mean that even dmenu is unsafe? If even dmenu is unsafe, can you give a concrete sequence of things to do that should break things? A specific program to run, key- or mouse click-sequence to hit, or so on? ~d

On Sun, Nov 13, 2011 at 17:33, 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

On Mon, Nov 14, 2011 at 13:58, Ferenc Wagner wrote:

Brandon Allbery writes:

...

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.

I guess you miss the Linux-only signalfd/eventfd, right?

"Linux-only" is the problem there. I know Linux folk like to imagine they define Unix and POSIX, but there are others out there still. Same problem with BSD's kqueue: I can't use it on Linux and only to a limited extent on OS X which has still another mechanism of its own (Mach ports). It's the *portable* general event interface that is missing. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms