Re: [matplotlib-devel] GTK threading

[Baptiste C. <bap...@al...>]

Hi,

Steve Chaplin a =E9crit :
> What situation would yield an "Xlib async reply"?
> =20
using your mt module:
   >>> import mt
   >>> mt.gui_cmd('print "OK"')
   OK
   >>> import matplotlib
   >>> matplotlib.interactive(1)
   >>> import pylab
   Xlib: unexpected async reply (sequence 0x4b)!

This is on linux, I don't know what you get on other platforms, but I=20
guess it's just as bad.

> How does it break method calls of matplotlib objects? In interactive
> mode the gtk backend does not work (by itself) so there's nothing to
> break
Well, it depends on how ambitious you are :-)

> When thinking about using threads for interactive mode I had been
> assuming people using the interactive mode would be using the pylab
> interface, does anyone use the matplotlib class interface in interactiv=
e
> mode?
>=20
I sometimes do. However, I've painted the situation worse than it is. I=20
almost only use the setter/getter methods, which are not dangerous.

One annoying thing though: error_msg will hang the gui:
   >>> import mt
   >>> mt.gui_cmd('from pylab import *')
   >>> mt.gui_cmd('plot([1,2])')
   >>> mt.gui_cmd('plot([1,2],"0r")')
   *** gui hangs here, you get the prompt back, but no gui commands will=20

       work ***

> In import_gtk() there is time.sleep(1) - what is that for?
>=20
This is an attempt to avoid a race condition were a proxy function would=20
be called before the GTK thread is initialized. I don't know if this=20
would lead to a real problem. 1s wait not that bad anyway.

> Shouldn't widget creation be protected as well by wrapping things like
> new_figure_manager() and FigureCanvasGTK(). I know __init__ is wrapped
> but objects may have __new__ methods which call gdk/gtk functions befor=
e
> __init__ is called.
>=20
I didn't think of that. Most GTK object are not dangerous until they are=20
shown.

> How about if a widgets standard methods such as show(), present() etc
> are used - they are not protected (unless called from a protected
> method). I think this just applies to using the class interface in
> interactive mode, so it may be rarely encountered but might be a
> problem.
>=20
As I stated, I didn't try to protect methods inherited from GTK objects=20
(ie not defined in matplotlib). Which means people using them are on=20
their own. You have to draw the boundary somewhere, unless you want to=20
implement a full gui_thread.

> Why use gtk_protect(), exec() and GTK_TEMPLATE, when you could use:
>=20
> def gtk_protect (fun):
>     def decorator (*args, **kwargs):
>
Well this was a try to set the proxy function name as the real function=20
name, in order to avoid weirdeness when reading object help. But I could=20
not set the argument spec correctly, so I ended up adding the 'proxy=20
from' line to the docstring. So I think all the GTK_TEMPLATE machinery=20
serves no purpose now.

As a final note, I have to say that the latest version of interactive.py=20
is good enough for my needs, so I'm no longer very motivated for pushing=20
this patch.

If you just need the pylab interface, you can also do it without=20
patching matplotlib. Just create a protected_pylab.py module, where you=20
would start the gui thread, define the gtk_protect function, import=20
pylab and define command=3Dgtk_protect(pylab.command) for every command i=
n=20
pylab. Then doing 'from protected_pylab import *' would give you a=20
working pylab interface, with just the error_msg problem.

Cheers,
Baptiste