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>