After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 686914 - pygobject still requires GObject.threads_init()
pygobject still requires GObject.threads_init()
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: gobject
unspecified
Other Linux
: Normal minor
: GNOME 3.10
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2012-10-26 07:25 UTC by Stef Walter
Modified: 2013-03-28 10:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test python program (1.04 KB, text/x-python)
2012-10-26 07:25 UTC, Stef Walter
  Details
Deprecate GLib and GObject threads_init (9.65 KB, patch)
2013-03-07 08:36 UTC, Simon Feltman
committed Details | Review

Description Stef Walter 2012-10-26 07:25:23 UTC
Created attachment 227328 [details]
Test python program

In C code g_threads_init() has recently been deprecated. But to use threads with python and pygobject, still requires a call to GObject.threads_init() or strange things happen.

Is this solveable, or is GObject.threads_init() with us to stay?

Will attach a test program. Uncomment the GObject.threads_init() line to make things work.
Comment 1 Marco Giusti 2012-10-26 07:40:50 UTC
It is not documented, or at least it is not easily findable, that GObject.threads_init() should be called. While you must do it in pygtk, the reference for PyGObject is the standard gtk documentation which does not mention it.
Comment 2 Marco Giusti 2012-10-26 08:07:21 UTC
Here a preliminary change to the wiki but this behavior should be documented somewhere in the python (c?) api.

https://live.gnome.org/action/info/PyGObject/IntrospectionPorting?action=diff&rev2=23&rev1=22
Comment 3 Martin Pitt 2012-10-26 08:59:47 UTC
pygobject itself hasn't called g_threads_init() for a long time, as it's deprecated and not necessary any more. pygobject's threads_init() is for Python thread handling (GIL), not for glib.

I'd like to get rid of this as well, if someone has an idea how to elegantly call this automatically if threads are being used? Or would it hurt to just always call this, i. e. does it result in a measurable performance degradation?
Comment 4 Marco Giusti 2012-10-26 10:02:24 UTC
While GObjects.threads_init() should be called before Gdk.init(), if the thread module is imported before a call to Gdk.init() or entering the main loop then most likely that function should be called.

But this is not really a solution because lazy importing the thread module will break anyway.
Comment 5 Simon Feltman 2013-03-06 11:47:00 UTC
It doesn't seem like any of the pyglib thread related functions are relevant any more. I replaced them with simple defines as follows in gi/_glib/pyglib.h:

#define pyglib_threads_enabled()    (TRUE)
#define pyglib_gil_state_ensure     PyGILState_Ensure
#define pyglib_gil_state_release    PyGILState_Release
#define pyglib_begin_allow_threads  Py_BEGIN_ALLOW_THREADS
#define pyglib_end_allow_threads    Py_END_ALLOW_THREADS

With this, I verified the example script works fine without calling GObject.threads_init(). The reason this was needed is because pyglib_gil_state_ensure and like functions were no-ops based on an internal variable (pyglib_threads_enabled), this would cause problems because the GIL would not be managed in this case.

Note Gdk.threads_init() is still needed if you want to call Gdk functions from a Python thread outside of the main thread. This is unrelated to GObject.threads_init.

The only reason something like GObject.threads_init would ever be needed is if GLib.Thread was usable from python and had the ability to run Python code. In this case what is really needed is a call to PyEval_InitThreads AFAICT. But GLib.Thread does not work and I don't know if it ever will from within Python.
Comment 6 Simon Feltman 2013-03-07 08:36:49 UTC
Created attachment 238275 [details] [review]
Deprecate GLib and GObject threads_init

Remove a handful of Python threading related helper functions
from pyglib and pygobject. The binding internals required
GLib.threads_init to be called for PyGObject to work with
Python threads. This was removed as it should not be a requirement.
Using the Python threading module already initializes threading
for us (PyEval_InitThreads).

Additional notes:
* pyglib.h is not distributed so we don't need to worry about API breakage.
* pygobject.h IS distributed so we need to keep set_thread_block_funcs around
Comment 7 Simon Feltman 2013-03-07 08:37:42 UTC
Targeting 3.10 to avoid any potential disruption this late in the release cycle.
Comment 8 Martin Pitt 2013-03-07 16:07:24 UTC
Comment on attachment 238275 [details] [review]
Deprecate GLib and GObject threads_init

Very nice, thanks Simon! This indeed helps to get rid of another weirdness.
Comment 9 Simon Feltman 2013-03-15 10:36:14 UTC
Additional note: Make sure we don't regress bug 678046, ideally add a regression tests for that along with this patch.
Comment 10 Martin Pitt 2013-03-25 08:17:54 UTC
Comment on attachment 238275 [details] [review]
Deprecate GLib and GObject threads_init

master has thawed, so please go ahead with this now. Thanks!
Comment 11 Simon Feltman 2013-03-28 10:11:42 UTC
Attachment 238275 [details] pushed as 48e5221 - Deprecate GLib and GObject threads_init