Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Jun 2009 08:07:16 -0800
From:      Mel Flynn <mel.flynn+fbsd.questions@mailing.thruhere.net>
To:        freebsd-questions@freebsd.org
Cc:        martin@dc.cis.okstate.edu, perryh@pluto.rain.com
Subject:   Re: Control-Z the Sleep Signal
Message-ID:  <200906100807.18528.mel.flynn%2Bfbsd.questions@mailing.thruhere.net>
In-Reply-To: <4a2f738c.vK%2B04C2hzxx8edYV%perryh@pluto.rain.com>
References:  <200906100204.n5A24J97018545@dc.cis.okstate.edu> <4a2f738c.vK%2B04C2hzxx8edYV%perryh@pluto.rain.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 10 June 2009 00:49:16 perryh@pluto.rain.com wrote:
> Martin McCormick <martin@dc.cis.okstate.edu> wrote:
> > 	Thanks to all. In this case, I made SIGTSTP have the
> > same effect in the program that CTRL-C does (SIGINT) so now
> > either signal makes the application remove the lock and quit
> > gracefully.
>
> To each his own, I guess.  To anyone familiar with the usual
> Unix/Linux conventions, this response to ^Z is going to be
> thoroughly unexpected.  Is there any reasonable way to do
> only the minimum cleanup need for the lock to be safely
> removed, and then suspend, reacquiring the lock when resumed?

Agreed. You're solving the wrong problem by mapping CTRL-Z to CTRL-C. The 
questions you should be asking are:
1) Why are stale locks bad for the app?
2) Why do stale locks occur to begin with?
3) Do the locks really solve the problem you thought you needed them for to 
begin with?
4) Why is it not possible to remove the locks if the PID that created them is 
not instance of said program?
-- 
Mel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906100807.18528.mel.flynn%2Bfbsd.questions>