Date: Tue, 14 Aug 2001 15:25:36 -0700 From: "brian o'shea" <boshea@netapp.com> To: Hans Zaunere <zaunere@yahoo.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Signal Handling Message-ID: <20010814152536.B27553@netapp.com> In-Reply-To: <20010813160932.30924.qmail@web12801.mail.yahoo.com>; from Hans Zaunere on Mon, Aug 13, 2001 at 09:09:32AM -0700 References: <20010813160932.30924.qmail@web12801.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 13, 2001 at 09:09:32AM -0700, Hans Zaunere wrote: [...] > However in reading about this, in Steven's Advanced > Programming in the UNIX Environment, he states: > "Naturally a signal that is being caught by a process > that calls exec cannot be caught in the new program, > since the address of the signal-catching function in > the caller probably has no meaning in the new program > file that is execed. Page. 273) > > This makes sense to me, however doesn't seem to be the > case. Three questions: This is true, except in the case where you exec() the same executable that called exec() in the first place. It sounds like this is what you are doing (calling exec() with argv[0] as the path to the new executable). In that case, the signal handler's address will be the same. Unix unsets the signal handler in the exec()ed process to handle the common case, which is that most people use exec() after a fork() to run a new executable. It is highly unlikely that the signal handlers for a given signal in two different executable files will have the same address. > 1) Why, in the first place, does a signal become > blocked after it is recieved? Why does the kernel > want to do this? I think it's to prevent the signal handler from being called while your process is alredy executing the handler. If your process receives signal 15, it is stopped by the kernel and the handler for that function is called. If while the handler is executing, the process receives signal 15 again, you don't want the signal handler to be called while it is already executing. Anybody else have some input on this? > 2) If a 10k binary is running, the signal is sent, and > the program is reloaded from disk, but is 100k (or 1k > even) how does the signal handling function get > called, taking into account what Stevens says. Steven > states that the sigmask remains for calls across exec, > so wouldn't the wrong address to the handler function > be used? No, the signal mask is not the address of the handler function. It is the bit mask which determines which signals are blocked. > 3) Is my using of exec, in fact, the best way to > reload the program on the fly, from within itself? > What would be the best, robust, way to do this in the > future? I think that exec() is the best way. -brian -- Brian O'Shea "Stare not too deeply into the pen, <boshea@netapp.com> 3.3.163(PEN) lest the pen stare back into you." (408) 822-3249 -------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010814152536.B27553>