[openbox] [RELEASE] Openbox 3.4.6 and ObConf 2.0.3

George De Bruin sndchaser at gmail.com
Sat Feb 2 14:21:09 EST 2008


Dana Jansens wrote:
> 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.
>   

Actually more than you might initially think.  It really depends on 
where the application is locking up.  If it's stuck waiting on some API 
call, which might be stuck on something, else, etc. Then it might not 
respond.  However if the application itself is still in control then it 
might respond.

Also, it depends on the structure of the application.  I can't speak to 
what works better for certain, but it seems that applications that are 
written in a client / server architecture with multiple threads are more 
likely to have better IPC than single threaded monolithic applications 
and a better chance of recovery.

I didn't think of this as a multiple click scenario, instead I thought 
of it as one click would try each of the signals one after another 
(excuse the sloppy psuedo-code):

    If not kill(TERM, PID) {
       If not kill(INT, PID) {
          If not kill(QUIT, PID) {
             ...
          }
       }
    }

Also, I forgot HUP in my list.  I think it should be tried before 
sending the STOP signal.

// George

> ---
> To unsubscribe, send a blank email to openbox-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?24
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SndChaser.vcf
Type: text/x-vcard
Size: 135 bytes
Desc: not available
URL: <http://icculus.org/pipermail/openbox/attachments/20080202/64ad682a/attachment.vcf>


More information about the openbox mailing list