Re: [pygtk] Hooking into Gtk iterations

[Hrvoje Niksic]

Aaron Optimizer Digulla <[EMAIL PROTECTED]> writes:

> Quoting Hrvoje Niksic <[EMAIL PROTECTED]>:
> 
> > > > > (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).
> > This is brain-dead on the part of Python, but that's another matter.
> > :-(
> 
> No, actually it´s braindead of Gtk

Python threads have the requirement that you always have access to the
interpreter, because one thread appears to lock all the others while
running.  This is abominable, and is a direct result of the
interpreter being non-thread-safe.

Gtk has the requirement that all Gtk actions are done in the same
thread, or that you implement semaphores on all Gtk entry-points.
This is abominable, and is a direct result of Gtk being
non-thread-safe.

So IMO they're both brain-dead and there's little we can do about it.
This is why I chose the SIGCHLD approach which also has its drawbacks, 
but appears to work in practice.
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] Hooking into Gtk iterations

[Aaron Optimizer Digulla]

Quoting Hrvoje Niksic <[EMAIL PROTECTED]>:

> > > > (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).
> This is brain-dead on the part of Python, but that's another matter.
> :-(

No, actually it´s braindead of Gtk but then, all X toolkits work this way.
Tcl has the same problem as well as Motif. I don´t know how Qt handles
this but I doubt that they can do this.

-- 
Aaron "Optimizer" Digulla Team AMIGA AROS Head of Development
Author of XDME, ResTrackLib, CInt. 
"(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]

Re: [pygtk] Hooking into Gtk iterations

[Hrvoje Niksic]

Aaron Optimizer Digulla <[EMAIL PROTECTED]> writes:

> The only solution I see is to add a timer:
> 
> def wakeup:
>   pass
> 
> timeout_add (100, wakeup)

I know of this solution and I will not use it, because it disallows my
program from ever being swapped out -- it continually consumes CPU
instead of simply waiting in poll() when nothing happens.  This is
(for me) inexcusable.

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

This is brain-dead on the part of Python, but that's another matter.
:-(
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] Hooking into Gtk iterations

[Aaron Optimizer Digulla]

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. 
"(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]

Re: [pygtk] Hooking into Gtk iterations

[Hrvoje Niksic]

James Henstridge <[EMAIL PROTECTED]> writes:

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

> (does it have anything to do with the threading code?).

I don't think so, no.
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] Hooking into Gtk iterations

[James Henstridge]

the quit_flag and call_quit_handlers() were pseudo code (I should probably
have made that more clear).  The quit_flag is actually a static variable
in gtkmain.c and the call_quit_handlers() is actually part of gtk_main()
(well it was last time I checked -- it probably is part of glib now).

As for doing a python no op, I have no idea how python triggers the
calling of signal handlers (does it have anything to do with the
threading code?). If anyone has any information, please speak up.

James Henstridge.

--
Email: [EMAIL PROTECTED]
WWW:   http://www.daa.com.au/~james/


On 25 Feb 1999, Hrvoje Niksic wrote:

> James Henstridge <[EMAIL PROTECTED]> writes:
> 
> > I suppose you could use an idle function.  It would get called for
> > each iteration of the main loop, and should allow the signal handler
> > to be called.
> 
> I tried that now, but idle functions suck for that purpose.  They are
> called all the time when my program is doing nothing, consuming the
> CPU.  I guess that in a sense "idle" functions are exactly the
> opposite of what I'm trying to achieve -- I'd like a no-op Python code 
> to be run when something *happens*, in case a signal happened.
> 
> Perhaps I should try to play with idle priorities?
> 
> > Basically mainloop() runs this:
> >   while quit_flag != TRUE:
> > mainiteration()
> >   call_quit_handlers()
> 
> Are quit_flag and call_quit_handlers() exported to Python?  Should
> they be?
> To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
> 

To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] Hooking into Gtk iterations

[Hrvoje Niksic]

James Henstridge <[EMAIL PROTECTED]> writes:

> I suppose you could use an idle function.  It would get called for
> each iteration of the main loop, and should allow the signal handler
> to be called.

I tried that now, but idle functions suck for that purpose.  They are
called all the time when my program is doing nothing, consuming the
CPU.  I guess that in a sense "idle" functions are exactly the
opposite of what I'm trying to achieve -- I'd like a no-op Python code 
to be run when something *happens*, in case a signal happened.

Perhaps I should try to play with idle priorities?

> Basically mainloop() runs this:
>   while quit_flag != TRUE:
>   mainiteration()
>   call_quit_handlers()

Are quit_flag and call_quit_handlers() exported to Python?  Should
they be?
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] Hooking into Gtk iterations

[James Henstridge]

I suppose you could use an idle function.  It would get called for each
iteration of the main loop, and should allow the signal handler to be
called.

Basically mainloop() runs this:
  while quit_flag != TRUE:
mainiteration()
  call_quit_handlers()

The quit handlers aren't called by mainiteration, nor is checking for
calls to mainquit.

James Henstridge.

--
Email: [EMAIL PROTECTED]
WWW:   http://www.daa.com.au/~james/


On 24 Feb 1999, Hrvoje Niksic wrote:

> As you may have noticed, I'm writing a program that tries to track
> several of its children.  It gets notified of a child's death by
> SIGCHLD.  The problem is that Python signal processing is synchronous
> -- while in the C signal handler, Python simply queues the routine to
> be run at a later time.  In some cases, this doesn't matter because a
> callback gets run because of the file descriptors that got closed.
> But in other cases, such as exec-ing "sleep 1", the subprocess' death
> goes unnoticed until the first time a Python callback is invoked.
> 
> I think this is fixable because of the fact that a signal will
> interrupt glib's poll.  I'd love to be able to specify code to be run
> between iterations.  The code would be a no-op, but it would be enough
> to let Python flush its queue.  For instance:
> 
> # Setup a dummy function that gives Python a chance to flush its
> # signal queues.
> iteration_add (lambda *args: TRUE)
> 
> Since I haven't found a way to do this, I tried a different approach;
> writing a mainloop myself, using the blocking version of
> gtk_main_iteration().  It looks like this:
> 
> class MainLoop:
> def __init__ (self):
> self.running = 1
> quit_add (1, self.__reset)
> while self.running:
> mainiteration (block = TRUE)
> 
> def __reset (self):
> print "called"
> self.running = 0
> 
> This code works nice as it is -- the death of "sleep 1" is now
> noticed.  The problem is that the above loop never exits because
> calling mainquit() doesn't invoke MainLoop.__reset__!  It was quite a
> shock to find out that mainquit() doesn't bother to call the stuff
> registered with quit_add(), even though mainiteration() is in
> progress.
> 
> I wonder if that's a bug or a feature...
> To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
> 

To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]