From: Richard Levitte - VMS Whacker (richard@levitte.org)
Date: Tue May 03 2005 - 14:32:30 CEST
In message <m2ekcotu9u.fsf@phoenix.squirrel.nl> on Tue, 03 May 2005 13:37:33 +0200, Johan Vromans <jvromans@squirrel.nl> said:
jvromans> Richard Levitte - VMS Whacker <richard@levitte.org> writes:
jvromans>
jvromans> > #define newhandler(sig, action) \
jvromans> > if (signal (sig, SIG_IGN) != SIG_IGN) (void) signal (sig, action)
jvromans> >
jvromans> > Now, if someone could explain to me why that macro is used at all, I'd
jvromans> > be quite grateful. Is there any reason at all not to set up a new
jvromans> > handler if the previous handler is SIG_IGN? That looks very error
jvromans> > prone to me...
jvromans>
jvromans> One thing that springs to mind (but I might be wrong) is
jvromans> that sometimes? ctwm is started with certain signals
jvromans> disabled (nohup?) and this macro prevents these disabled
jvromans> signals from being reenabled?
Actually, considering we're doing execvp from inside a signal handler,
we're on undefined territory. Changing newhandler(SIGHUP, Restart) to
signal(SIGHUP, Restart) didn't change anything, so I'm guessing the
signal is permanently blocked until ctwm gets out of the first signal
handler... eh... or something like that.
There are several possibilities available:
- use sigaction() instead of signal(). It's quite a bit more robust,
and it's possible to say how a handler should be treated. This
needs quite a lot of care.
- have Restart() set a flag. This requires a wrapper around
XNextEvent(), probably using select().
- something different that I haven't come up with yet.
Cheers,
Richard
-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte richard@levitte.org
http://richard.levitte.org/
"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis
This archive was generated by hypermail 2.1.4 : Wed May 04 2005 - 06:45:03 CEST