] >Date Index
Re: [wmx] I think there _is_ a problem w/ using SIGHUP to restartO'Shaughnessy Evans
- Thu Aug 05 19:18:11 1999
James Ramsey <firstname.lastname@example.org> wrote:
> I was talking with my dad last night, who unlike me _is_ a programmer
> and has been so for 30+ years, and mentioned wmx's scheme for
> restarting. He thought SIGHUP would be a bad choice since it is
> typically used as a way of telling apps to terminate. I believe it goes
> back to the days of timesharing: you dial up, literally, a big server,
> do what you need to do with it, and when you're done, you _hang up_ the
> connection, which terminates the apps you were running on the server.
> Or something like that. The applications that you mentioned that
> restart on SIGHUP, like httpd and Apache, are apps for which the SIGHUP
> signal is literally meaningful, and are probably doing the Right Thing
Hmm. With Apache, and other servers like inetd and BIND, SIGHUP is a
control signal used by the admin to force it to reload its configuration.
Just like those apps, I've been thinking that we want wmx to reinitialize
itself when we send it a HUP. We aren't using it in a mainframe/
timesharing world -- we're using it in the Unix world, where it's natural
to expect an app to reload itself on HUP. If wmx were operating in a
terminal I/O context, using HUP could get confusing, but I think in this
context it makes some sense. Wmx isn't a server, though, and the primary
context for the HUP paradigm is when controlling daemons (AFAIK), so this
may invalidate my point. I have seen at least one other window manager
use HUP like this as well, though.
But I still understand your argument against it. After all, I think this
is the kind of situation for which the SIGUSR signals were created.
Perhaps it would be best to follow the Principle of Least Surprise here
and see what other window managers use as a cue to reload themselves.
> (TM). In the case of wmx, if you use SIGHUP to restart, you will
> probably end up stepping on something or do something that will confuse
> another app. I believe that session managers, for one, use SIGHUP to
> terminate the apps in an X session.
> SIGUSR1 is probably the appropriate signal to send to wmx to tell it to
> restart. It's an application-defined signal that has no meaning other
> than the one that the application gives it. It won't step on anything,
Hmm. I don't see how sending a HUP to wmx will force it to step on
anything. Will the signal necessarily get passed on to wmx's children?
"the correct answer is usually 'mu', a Japanese word alleged to mean 'Your
question cannot be answered because it depends on incorrect assumptions'."
-- The New Hacker's Dictionary, on "mu"