"Luca Minuti" <[EMAIL PROTECTED]> writes:
> #!/usr/bin/env python
>
> from signal import *
> from gtk import *
>
> def signal_handler(sig, frame):
> print "Received signal %s" % (sig)
>
> signal(10, signal_handler)
>
> win = GtkWindow()
> win.set_usize(100,100)
> win.show()
> win.connect("destroy", mainquit)
> mainloop()
>
> but if I write:
>
> $ kill -s 10 <pid>
>
> the program answer only after the mainquit.
I've hit this problem before[1], and it boiled down to a problem with
Gtk/Python interaction. You should know that in Python signals are
never really asynchronous. When the OS/C-level signal handler is
invoked, Python merely enqueues the Python handler to a special queue,
to be executed by the Python interpreter as soon as possible.
The problem with Gtk is that when the signal handler returns, it gives
back control to the Gtk main loop, not to Python, so the code that is
supposed to check for the signal-handler queue gets run only when the
interpreter exits.
The solution here is for pygtk to hook into the main loop with a
routine that gets run after the loop has been interrupted by a signal.
This routine would manually call the Python signal-handling
incantation. Alas, last time I looked, GDK main loop didn't have that
kind of hook. I asked about it on the Gtk list, but got no response.
James, have you looked into the features of GDK main loop recently?
Can you now specify a "post-signal" handler nowadays?
[1]
Before someone jumps with "don't use UNIX signals in a GUI
application", let me assure you that it was hard to do otherwise. My
Gtk program spawned off a bunch of child processes, and was interested
in their exit statuses. Apparently the only wait to find out when a
process has died is to handle SIGCHLD. I haven't found the solution
to the problem, and gave up the application entirely.
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
