On Wed, 2011-12-14 at 20:03 +1100, Rodney McDonell wrote: > I'm hoping that some people on here will try this patch and tell me of > there successes or failures. This is my first contribution to the Open > Source community, so if you have some critical comments, let them fly, > I'm eager to learn.
The idea is quite cool. There are some technical issues with it, both
with the idea in general and with your implementation in particular.
From a quick read of your patch (not looking much at the rest of
blackbox, but assuming it's a fairly normal wm) I think you have a race
condition. X11 is an async protocol, and some of its race conditions
can only be cured with a thing called a server grab, which allows a
single client to monopolize the server's attention. This means that,
during the instant you're deciding to send SIGSTOP to the app, it can
have taken a server grab. Now you're deadlocked; the server won't
listen to any other clients until the app wakes up, but the app will
never wake up because the kernel will never schedule it.
The fix looks something like:
XGrabServer(display);
/*
* Wait for a reply, so we know the server is actually giving us
* attention (instead of our grab being stuck in the queue behind
* an existing grabbing client).
*/
XSync(display, 0);
/* do signal stuff */
XUngrabServer(display);
I suspect this is not the only race.
The other thing that comes to mind is, just because you paused a process
doesn't mean other processes will stop talking to it. The app has
probably already asked the X server to send events, which it has to do
regardless of whether the app is SIGSTOPped or not. So now you're
leaking memory, because either the kernel's socket buffers or the X
server's internal buffering has to keep track of all the events that
will one day successfully be written to the client. You could probably
adequately work around this by periodically unpausing applications for a
few dozen milliseconds. It's still going to be a hack, but strictly
speaking it's a failure condition that's present in base X even without
this patch.
> P.S This is for a laptop PC primarily. It wont work too well or may have
> undesirable effects if your remote Xing. If anyone has any ideas on how
> to detect, from a Window Manager if a Windows process is remote or not,
> do give me a hint :).
Refer to the EWMH spec, particularly this bit:
http://standards.freedesktop.org/wm-spec/1.3/ar01s07.html#KILLINGWINDOWS
- ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Power mailing list Power@bughost.org https://bughost.org/mailman/listinfo/power
