[openbox] [RELEASE] Openbox 3.4.6 and ObConf 2.0.3
danakj at orodu.net
Sat Feb 2 14:09:14 EST 2008
2008/2/2 George De Bruin <sndchaser at gmail.com>:
> Dana Jansens wrote:
> > * Application windows which support the appropriate protocols will
> > now show [Not Responding] in their titlebars when the application has
> > frozen up. By closing the window while the [Not Responding] message is
> > visible, Openbox will kill the window's process, allowing you to kill
> > frozen applications without dropping to the command line. If the
> > window still won't close after the first try, a further close attempt
> > will use kill -9.
> As a feature, while this sounds good, it's not the best way to handle
> this situation. Signal 9 (KILL) should only be used as a last resort as
> it doesn't give the application any chance to do a graceful exit, and
> will result in lost data if there are files open. There are quite a few
> other signals that should be tried before KILL: INT, QUIT, ABRT, TERM,
> and STOP should definitely all be tried before KILL as the response to
> them may allow a clean exit of the application. In some cases, CONT,
> USR1 and USR2 may even be of benefit, but it is definitely a little less
> certain what will happen.
> At this point, from the way your description is written, it does sound
> like you use TERM first, then resort to KILL. Personally, I would
> prefer to see OpenBox trying: TERM, INT, QUIT, ABRT, STOP, and finally
> KILL. Even if the application doesn't terminate until it is killed,
> there is a much better chance that it might does some kind of cleanup in
> response to one of the other signals.
I see your point, however clicking the close button 7 times seems to
be a bit of an unreasonable requirement, so I don't know.. How many
apps really don't respond to TERM but respond to other signals? I
don't image very many.
More information about the openbox