Re: UNIX signal handling

[Owen Taylor <otaylor redhat com>]

Andy Kahn <kahn@zk3.dec.com> writes:

> hi Owen,
> 
> > > 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.
> 
> thanks for your reply.  i have a few more questions/comments:
> (please excuse my ignorance related to X since i'm nowhere
> close to being an expert in X)
> 
> 
> > * 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.
> 
> isn't using shared memory an X11 extension?  and not all X servers
> use even if shared memory is available?  if this is the case, it
> seems to make more sense to have gdk_signal() "enabled" only for
> the shared memory cleanup case.  of course, this is assuming there
> isn't another use for it.  which leads to...

Yes, but it is a very common extension. It basically will
always be present when you are running the X server locally.

It would be possible to be smart and disable the signal handlers
in the cases they aren't needed, but I'm not sure if that
is a good idea. If they are a problem for an application,
then if they are disabled on the machine the developer is
developing on, the developer will be in for a nasty suprise
when other people start to use the program. I think an
all-or-none approach is probably better than conditionalizing
it.

For debugging core dumps, any developer should be
compiling with --enable-debug, and you can generally get
a traceback for reproducible problems by running even
a non-enable-debug version of GTK+ under a debugger.
(The debugger will trap the SEGV signal).
 
> > * 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.
> 
> is this really necessary?  would it be possible for any program
> that needs to gdk_key_repeat_disable() to install their own
> signal handler to cleanup and restore the repeat key?  this
> seems to make more sense to me since gdk_key_repeat_disable()
> does not appear to be used anywhere in gdk/gtk itself, so it's
> not something that's necessary to the execution of gdk/gtk.
> hence, let whomever needs to use it (e.g, the application)
> cleanup after itself.

I'm more concerned about the shared memory segments. I'd
like to get rid of the global key-repeat setting in any case.

Regards,
                                        Owen