In message <[EMAIL PROTECTED]> on Tue, 03 May 2005 13:37:33 +0200, Johan Vromans <[EMAIL PROTECTED]> said:
jvromans> Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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
