Re: UNIX signal handling
- From: Owen Taylor <otaylor redhat com>
- To: Andy Kahn <kahn zk3 dec com>
- Cc: Daniel Solaz <dsolaz sistelcom com>, gtk-list redhat com
- Subject: Re: UNIX signal handling
- Date: 10 Jul 1998 15:35:43 -0400
Andy Kahn <kahn@zk3.dec.com> writes:
> On Fri, Jul 10, 1998 at 07:20:56PM +0200, Daniel Solaz wrote:
> > The HTML docs simply state that GTK will install several signal
> > handlers. I'm talking about unix signals now.
> > What purpose do they serve? Do they clean up things on exit? Is there
> > any reason why resetting them would be a bad idea?
> > -Daniel
> >
>
> i dug around in this area as well and found that in gdk_init(), signal
> handlers are installed for SIGHUP, SIGINT, SIGQUIT, SIGBUS, SIGSEGV,
> SIGPIPE, and SIGTERM (effectively, all the "fatal" signals). they are
> all caught with one signal handler, gdk_signal(). but if you take a
> look at gdk_signal(), it really does nothing useful!
Yes and no. There are actually two important things that gdk_signal()
does.
* The reason that it was originally added, I think, was to
destroy shared memory segments that were created for X images.
This isn't as important now, since GTK+ when possible uses
IPC_RMID to do a deferred destroy when the last program
detaches, but there are, I think, still programs, where
without gdk_signal() control-C'ing out of a GTK program
will leak shared memory segments.
* Also, gdk_key_repeat_disable() disables key-repeat globally,
so the exit function tries to restore that. That the
key-repeat is global is a defect of X, but I think it
may be possible to work around that by looking for
key-release / press pairs with identical timestamps and
ignoring them.
So the purpose wasn't just to hide the core and print out
a pretty error message, though on most platforms in most
cases, that's what it works out to.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]