Re: UNIX signal handling

[Owen Taylor <otaylor redhat com>]

"Daniel Solaz" <dsolaz@sistelcom.com> writes:

> Owen Taylor wrote:
> >* 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.
>
> I don't know much about IPC.  When would pressing Ctrl-C really be a
> problem?

When you create an image with GTK+, it will, if possible, use a shared
memory segment to communicate with the X server.  Shared memory
segments are not by default destroyed when all applications using them
quit, so if GTK+ is killed without being able to delete the segment,
the segment will hang around taking up a chunk of virtual memory until
the user notices something is wrong, or until they reboot their
machine.

On many platforms, GTK+ is able to take advantage of an extra feature
in the SysV IPC mechanism where you _can_ specify that a segment
should be deleted when the last app using it quits. This feature is
not, however, universal, (there is an autoconf test for it).

Regards,
                                        Owen