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 606775 - Enable threads by default in gobject
Enable threads by default in gobject
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.23.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2010-01-12 20:34 UTC by Alexander Larsson
Modified: 2010-06-17 07:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Relax g_thread_init() requirements (4.48 KB, patch)
2010-01-12 20:37 UTC, Alexander Larsson
committed Details | Review
Enable threads in g_type_init() (3.81 KB, patch)
2010-01-12 20:37 UTC, Alexander Larsson
committed Details | Review
Make thread calls unconditional if G_THREADS_MANDATORY is set (1.24 KB, patch)
2010-01-12 20:37 UTC, Alexander Larsson
committed Details | Review
Use unconditional thread calls in gio and gobject (2.10 KB, patch)
2010-01-12 20:37 UTC, Alexander Larsson
committed Details | Review

Description Alexander Larsson 2010-01-12 20:34:29 UTC
Proposal to enable threads in gobject here:

http://www.mail-archive.com/gtk-devel-list@gnome.org/msg11139.html

Seems to be generally approved, will attach patches.
Comment 1 Alexander Larsson 2010-01-12 20:37:21 UTC
Created attachment 151283 [details] [review]
Relax g_thread_init() requirements

We now allow g_thread_init(NULL) to be called after other glib calls (with
some minor limitations). This is mainly a documentation change as this
really was already possible.

We also allow g_thread_init() to be called multiple times. Only the
first call actually initializes the threading system, further calls
are ignored (but print a warning if the argument is not NULL).
Comment 2 Alexander Larsson 2010-01-12 20:37:30 UTC
Created attachment 151284 [details] [review]
Enable threads in g_type_init()

This means threads will be supported for all gobject libraries/applications
and initialized early enough to not cause any problems.

This solves the problem of libraries needing threadsafety. Previosly
they just called g_threads_init() anyway, which often works but sometimes
breaks in unexpected ways.

See this thread for more details:
http://mail.gnome.org/archives/gtk-devel-list/2009-November/msg00208.html
Comment 3 Alexander Larsson 2010-01-12 20:37:42 UTC
Created attachment 151285 [details] [review]
Make thread calls unconditional if G_THREADS_MANDATORY is set

Since gobject now initialized threads unconditionally if threads are
available it makes no sense to have each thread operation
conditionally check if threads are enables, so allow this to be avoided.
Comment 4 Alexander Larsson 2010-01-12 20:37:52 UTC
Created attachment 151286 [details] [review]
Use unconditional thread calls in gio and gobject

If threads are available we always enable threads in gobject, which
means all gio/gobject code can enable the unconditional thread calls.

This is a minor optimization since we avoid a bunch of unnecessary
is-threads-enabled checks.
Comment 5 Alexander Larsson 2010-01-12 20:59:21 UTC
Attachment 151283 [details] pushed as 0df3ca8 - Relax g_thread_init() requirements
Attachment 151284 [details] pushed as fa2bced - Enable threads in g_type_init()
Attachment 151285 [details] pushed as de5c708 - Make thread calls unconditional if G_THREADS_MANDATORY is set
Attachment 151286 [details] pushed as 94b8613 - Use unconditional thread calls in gio and gobject
Comment 6 Martin von Gagern 2010-06-16 09:31:55 UTC
This change causes nspluginscan from KDE 3.5 to crash. The reason seems to be that the totem 2.30.0 plugin uses g_content_type_get_description without sufficient initialization of the gio library, thus causing a null function reference trying to assume a lock.

See https://bugs.gentoo.org/324237 for further details.

Which function should libraries like totem call in order to ensure proper initialization without violating any of the past "call only once" restrictions?
Comment 7 Martin von Gagern 2010-06-16 12:28:42 UTC
(In reply to comment #6)
> This change causes nspluginscan from KDE 3.5 to crash. The reason seems to be
> that the totem 2.30.0 plugin uses g_content_type_get_description without
> sufficient initialization of the gio library, thus causing a null function
> reference trying to assume a lock.

Filed this particular problem as bug #621771.
Comment 8 Alexander Larsson 2010-06-17 07:29:35 UTC
Martin: Calling gio without initializing g_type_init() is a clear bug (as gio is a gobject based library). g_type_init() can be called multiple times, and if its called there will not be any thread intialization related problems with newer glibs.