Re: UNIX signal handling

[Andy Kahn <kahn zk3 dec com>]

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...


> * 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.
--andy