Quoting Hrvoje Niksic <[EMAIL PROTECTED]>:
> > As for doing a python no op, I have no idea how python triggers the
> > calling of signal handlers
> The signal handlers are queued up somewhere; Python will empty the
> queue as soon as it gets the chance -- I'm certain of that. A no-op
> would be quite sufficient for that.
The problem here is that Python is blocked: while the mainloop runs no
Python code is executed (Gtk has control, Python waits to get the control
back). When a callback is invoked, control goes back to Python and that's
why the signal handlers are processed when a callback is triggered.
The only solution I see is to add a timer:
def wakeup:
pass
timeout_add (100, wakeup)
which gets called 10 times per second (IIRC, it could also be 0.1 instead
of 100) and allows Python to run.
> > (does it have anything to do with the threading code?).
> I don't think so, no.
Yes, that's the same. Threading doesn't work with the current
implementation of Gtk because all Python threads are dead as long as Gtk
waits in its mainloop for events (no Python code is executed -> Python
can't switch the threads). I've complained to the Gtk/Glib developers about
this several times but to no avail. The only solution I see is to
re-implement the mainloop of glib in Python so that we could put it into a
Python thread thus allowing Python to switch threads.
--
Aaron "Optimizer" Digulla Team AMIGA AROS Head of Development
Author of XDME, ResTrackLib, CInt. <http://www.aros.org/>
"(to) optimize: Make a program faster by improving the algorithms rather than
by buying a faster machine." <[EMAIL PROTECTED]>
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
