Proposal: Enable threads by default

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: Enable threads by default

Alexander Larsson
This was previously discussed here, but was sort of hidden in a
technical discussion so it got no replies. I'm starting over in order to
reach a wider target for the discussion.

I'll start with the proposal and then explain the reasons for it:

Starting with next glib release:
* libgobject links to libgthread
* g_type_init() starts with:

#ifdef G_THREADS_ENABLED
 if (g_thread_supported())
   g_thread_init (NULL);
#endif

This means that everything above gobject can rely on thread primitives
being availible, and that global stuff in glib (mainloop, gslice,
globals, etc) are threadsafe.

It also means that simple apps that just use the datatypes and utilities
in glib (and don't use gobject) won't require threads.

Note however, that this doesn't mean that GDK/GTK are threadsafe by
default. That is an additional thing, and it can't even be enabled by
default because it requires changes in non-threadsafe applications. So,
apps still need to call gdk_threads_init().

It also allows applications to call g_thread_init() before g_type_init()
in order to specify custom threading primitives.

So, what is the reason for this?

The current system (apps have to call g_threads_init() before any other
glib functions) works for applications that need to use threads.
However, it breaks down when libraries or plugins need to use threads.
Since its not allowed to call g_thread_init() late these libraries can't
use threads at all unless the application initialized them, which many
don't.

Additionally, and part of the problem, is that current glib allows late
initialization, or at least it doesn't crash in flames if you do so.
However, there is no guarantee that this doesn't break in weird ways as
a lot of threadsafe code doesn't correctly handle late thread
initialization (including libgio, see bug 595757). In fact, outside of
libglib its not really possible to sanely handle it.

ORBit2 (and thus gconf which uses it) initializes threads late, so in
practice most applications actually initialize threads, but in a broken
and risky way.

Historically we've avoided threads a lot because the cost of just having
basic thread-safety was to high. But, with the current situation
(futexes/NPTL/g_slice) things have improved a lot on the software side,
so the costs are not as bad anymore. And threads are starting to become
more important these days too, with multi-core processors and gio using
threads for async local i/o.

So, while I personally still recommend people to not use threads unless
they have a very good reason, I think that we are now at a place where
its used widely enough and is important enough that we need to be able
to rely on the basic threading primitives in our libraries and plugins
by default. It would be nice to be able to drop the whole thread
initialization issue for Gnome 3.0.


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Benjamin Otte
Alexander Larsson <alexl <at> redhat.com> writes:
> Starting with next glib release:
> * libgobject links to libgthread
> * g_type_init() starts with:
>
> #ifdef G_THREADS_ENABLED
>  if (g_thread_supported())
>    g_thread_init (NULL);
> #endif
>
Finally.

I'm so sick of the issues (mostly performance-related) that crop up due to
threading/no threading/late threading in all the various applications, that I'm
really happy to see this happen. One less vector hard-to-trigger bugs can creep
into the code.

Benjamin


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Christian Dywan-3
In reply to this post by Alexander Larsson
Am Thu, 26 Nov 2009 14:35:36 +0100
schrieb Alexander Larsson <[hidden email]>:

> This was previously discussed here, but was sort of hidden in a
> technical discussion so it got no replies. I'm starting over in order
> to reach a wider target for the discussion.
>
> I'll start with the proposal and then explain the reasons for it:
>
> Starting with next glib release:
> * libgobject links to libgthread
> * g_type_init() starts with:
>
> #ifdef G_THREADS_ENABLED
>  if (g_thread_supported())
>    g_thread_init (NULL);
> #endif
>

You mean this:

if (!g_thread_supported ())
  g_thread_init (NULL);

Just to prevent confusion. Since the above snippet wouldn't work. :)

ciao,
    Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Tim-Philipp Müller
In reply to this post by Alexander Larsson
On Thu, 2009-11-26 at 14:35 +0100, Alexander Larsson wrote:

> Starting with next glib release:
> * libgobject links to libgthread
> * g_type_init() starts with:
>
> #ifdef G_THREADS_ENABLED
>  if ([!]g_thread_supported())
>    g_thread_init (NULL);
> #endif
>
> This means that everything above gobject can rely on thread primitives
> being availible, and that global stuff in glib (mainloop, gslice,
> globals, etc) are threadsafe.

Yes, please!

 Cheers
  -Tim


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Alexander Larsson
In reply to this post by Christian Dywan-3
On Thu, 2009-11-26 at 18:27 +0100, Christian Dywan wrote:

> Am Thu, 26 Nov 2009 14:35:36 +0100
> schrieb Alexander Larsson <[hidden email]>:
>
> > This was previously discussed here, but was sort of hidden in a
> > technical discussion so it got no replies. I'm starting over in
> order
> > to reach a wider target for the discussion.
> >
> > I'll start with the proposal and then explain the reasons for it:
> >
> > Starting with next glib release:
> > * libgobject links to libgthread
> > * g_type_init() starts with:
> >
> > #ifdef G_THREADS_ENABLED
> >  if (g_thread_supported())
> >    g_thread_init (NULL);
> > #endif
> >
>
> You mean this:
>
> if (!g_thread_supported ())
>   g_thread_init (NULL);
>
> Just to prevent confusion. Since the above snippet wouldn't work. :)

Yeah, thats what i mean. Thanks.


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Alexander Larsson
In reply to this post by Alexander Larsson
On Thu, 2009-11-26 at 14:35 +0100, Alexander Larsson wrote:

> This was previously discussed here, but was sort of hidden in a
> technical discussion so it got no replies. I'm starting over in order
> to
> reach a wider target for the discussion.
>
> I'll start with the proposal and then explain the reasons for it:
>
> Starting with next glib release:
> * libgobject links to libgthread
> * g_type_init() starts with:
>
> #ifdef G_THREADS_ENABLED
>  if (g_thread_supported())
>    g_thread_init (NULL);
> #endif
>
> This means that everything above gobject can rely on thread primitives
> being availible, and that global stuff in glib (mainloop, gslice,
> globals, etc) are threadsafe.
I'm attaching a patch that implements this.

In addition to enabling threads (if complied in) in g_type_init() it
adds a G_THREADS_MANDATORY define that if set causes all the
g_thread_supported() calls to be removed in the g_thread_* macros.

We then pass -DG_THREADS_MANDATORY in gobject and gio if threads are
enabled, letting us avoid a bunch of checks of the
g_threads_got_initialized global variable. I'm not sure how important
this is, but it got rid of 2186 bytes of code in libgobject.so, and it
just seems wrong to constantly check this when its always true.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc
       [hidden email]            [hidden email]
He's an immortal pirate gangster from the 'hood. She's an orphaned
nymphomaniac detective on the trail of a serial killer. They fight crime!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

gobject-enable-threads.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Dan Winship-2
On 12/01/2009 08:29 AM, Alexander Larsson wrote:
> In addition to enabling threads (if complied in) in g_type_init() it
> adds a G_THREADS_MANDATORY define that if set causes all the
> g_thread_supported() calls to be removed in the g_thread_* macros.

Should probably add that to Cflags in gobject-2.0.pc.in too?

Also, do we want to get rid of the possibility of compiling glib without
threads? Allowing threadless glib means we still need to have the
non-threaded versions of GIOScheduler, GResolver, etc, lying around, but
they'll never get used in normal builds.

-- Dan
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Alexander Larsson
On Tue, 2009-12-01 at 09:26 -0500, Dan Winship wrote:
> On 12/01/2009 08:29 AM, Alexander Larsson wrote:
> > In addition to enabling threads (if complied in) in g_type_init() it
> > adds a G_THREADS_MANDATORY define that if set causes all the
> > g_thread_supported() calls to be removed in the g_thread_* macros.
>
> Should probably add that to Cflags in gobject-2.0.pc.in too?

I don't think that is quite right. Its only safe to set this define if
you can guarantee there is no calls to your code before g_type_init (or
g_thread_init directly) is called. This is true for gobject (must call
g_type_init first) and gio (100% gtype library). However, one could
imagine some library of e.g. utility functions that have stuff you can
use before g_type_init() is called.

> Also, do we want to get rid of the possibility of compiling glib
> without
> threads? Allowing threadless glib means we still need to have the
> non-threaded versions of GIOScheduler, GResolver, etc, lying around,
> but
> they'll never get used in normal builds.

I wouldn't mind this, but on the other hand its not really a large
maintainance burden, is it?

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc
       [hidden email]            [hidden email]
He's an obese devious vagrant fleeing from a secret government programme.
She's a chain-smoking mutant opera singer with her own daytime radio talk
show. They fight crime!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Dan Winship-2
On 12/01/2009 03:36 PM, Alexander Larsson wrote:
> I don't think that is quite right. Its only safe to set this define if
> you can guarantee there is no calls to your code before g_type_init (or
> g_thread_init directly) is called.

Hrmph. Could potentially add a define which would cause a G_LIKELY() to
be added in to G_THREAD_CF() when linking to gobject... but we'd want to
test that it actually had a measurable effect first.

>> threads? Allowing threadless glib means we still need to have the
>> non-threaded versions of GIOScheduler, GResolver, etc, lying around,
>> but
>> they'll never get used in normal builds.
>
> I wouldn't mind this, but on the other hand its not really a large
> maintainance burden, is it?

Continuing to maintain the existing code which we already know works is
not a large burden, but having to write non-threaded versions of *new*
APIs might suck (having to write *two* non-threaded versions of
GResolver did) and then after we write them they're never going to get
used and so they'll probably be all buggy anyway. And besides, who are
we providing the no-thread-support version for anyway? There used to be
some somewhat-relevant unixes without pthreads, but I don't think there
are any non-toy OSes that have that problem any more.

-- Dan
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Alexander Larsson
On Tue, 2009-12-01 at 16:16 -0500, Dan Winship wrote:

> On 12/01/2009 03:36 PM, Alexander Larsson wrote:
> > I don't think that is quite right. Its only safe to set this define
> if
> > you can guarantee there is no calls to your code before g_type_init
> (or
> > g_thread_init directly) is called.
>
> Hrmph. Could potentially add a define which would cause a G_LIKELY()
> to be added in to G_THREAD_CF() when linking to gobject... but we'd want
> to test that it actually had a measurable effect first.

Actually, why are the thread primitives using g_thread_supported() at
all? They're all virtualized anyway, can't we just change the default
operation to be some non-NULL version that does what the
!g_thread_supported case does?
 

> > I wouldn't mind this, but on the other hand its not really a large
> > maintainance burden, is it?
>
> Continuing to maintain the existing code which we already know works
> is not a large burden, but having to write non-threaded versions of *new*
> APIs might suck (having to write *two* non-threaded versions of
> GResolver did) and then after we write them they're never going to get
> used and so they'll probably be all buggy anyway. And besides, who are
> we providing the no-thread-support version for anyway? There used to
> be some somewhat-relevant unixes without pthreads, but I don't think
> there are any non-toy OSes that have that problem any more.

I'm certainly for this. Does anyone know of any system in use where
gthreads are not availible?

Another aspect is that you might want to disable threads in e.g. an
embedded system where they are not used. I'm not sure people actually do
this though, since embedded systems large enough to run e.g. gtk or
other gobject things are generally big enough that you can support
threads and you're likely to actually want to use things like
threadpools and async i/o.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc
       [hidden email]            [hidden email]
He's a lonely white trash assassin who dotes on his loving old ma. She's a
vivacious foul-mouthed magician's assistant from the wrong side of the tracks.
They fight crime!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Alexander Larsson
In reply to this post by Alexander Larsson
On Tue, 2009-12-01 at 14:29 +0100, Alexander Larsson wrote:

> On Thu, 2009-11-26 at 14:35 +0100, Alexander Larsson wrote:
> > This was previously discussed here, but was sort of hidden in a
> > technical discussion so it got no replies. I'm starting over in
> order
> > to
> > reach a wider target for the discussion.
> >
> > I'll start with the proposal and then explain the reasons for it:
> >
> > Starting with next glib release:
> > * libgobject links to libgthread
> > * g_type_init() starts with:
> >
> > #ifdef G_THREADS_ENABLED
> >  if (g_thread_supported())
> >    g_thread_init (NULL);
> > #endif
> >
> > This means that everything above gobject can rely on thread
> primitives
> > being availible, and that global stuff in glib (mainloop, gslice,
> > globals, etc) are threadsafe.
>
> I'm attaching a patch that implements this.

Running with this patch i ran into an issue while building gnome-shell:

  GEN    Gdm-1.0.gir

GThread-ERROR **: GThread system may only be initialized once.
aborting...
Command '['/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/Gdm-1.0',
'--introspect-dump=/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/types.txt,/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/dump.xml']' returned non-zero exit status -5

Not sure exactly what crashed, but obviously something ran:
g_type_init() and then g_thread_init(). Maybe we need to make this a
non-fatal warning?

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc
       [hidden email]            [hidden email]
He's a notorious bohemian librarian from a doomed world. She's a beautiful
renegade lawyer with the soul of a mighty warrior. They fight crime!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

jcupitt
In reply to this post by Alexander Larsson
2009/12/2 Alexander Larsson <[hidden email]>:
> I'm certainly for this. Does anyone know of any system in use where
> gthreads are not availible?

One problem I've had in the past is writing mysql plugins.

I help maintain an image processing library, and one use of the
library was a mysql plugin that added query-by-image-content. To get
the plugin working we had to make sure we could run threadless.

I've not actually checked for years, perhaps mysql allows plugins to
link to more stuff now.

John
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Alexander Larsson
On Wed, 2009-12-02 at 11:48 +0000, [hidden email] wrote:
> 2009/12/2 Alexander Larsson <[hidden email]>:
> > I'm certainly for this. Does anyone know of any system in use where
> > gthreads are not availible?
>
> One problem I've had in the past is writing mysql plugins.
>
> I help maintain an image processing library, and one use of the
> library was a mysql plugin that added query-by-image-content. To get
> the plugin working we had to make sure we could run threadless.

By threadless, do you mean not linking to the thread library, or do you
mean "don't spawn threads". Because initializing threads doesn't mean
we'll create threads, just that we make global us data threadsafe.


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc
       [hidden email]            [hidden email]
He's a time-tossed coffee-fuelled gangster with a robot buddy named Sparky.
She's a supernatural tomboy former first lady with the power to bend men's
minds. They fight crime!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

jcupitt
2009/12/2 Alexander Larsson <[hidden email]>:

> On Wed, 2009-12-02 at 11:48 +0000, [hidden email] wrote:
>> 2009/12/2 Alexander Larsson <[hidden email]>:
>> > I'm certainly for this. Does anyone know of any system in use where
>> > gthreads are not availible?
>>
>> One problem I've had in the past is writing mysql plugins.
>>
>> I help maintain an image processing library, and one use of the
>> library was a mysql plugin that added query-by-image-content. To get
>> the plugin working we had to make sure we could run threadless.
>
> By threadless, do you mean not linking to the thread library, or do you
> mean "don't spawn threads". Because initializing threads doesn't mean
> we'll create threads, just that we make global us data threadsafe.

Sorry, I wasn't clear. You mustn't even link to pthreads when building
mysql plugins.

Or that used to be the case anyway. I tried a quick google but
couldn't find anything saying whether or not this was still a problem,
so this might all be a red herring anyway.

John
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Alexander Larsson
On Wed, 2009-12-02 at 13:07 +0000, [hidden email] wrote:

> 2009/12/2 Alexander Larsson <[hidden email]>:
> > On Wed, 2009-12-02 at 11:48 +0000, [hidden email] wrote:
> >> 2009/12/2 Alexander Larsson <[hidden email]>:
> >> > I'm certainly for this. Does anyone know of any system in use
> where
> >> > gthreads are not availible?
> >>
> >> One problem I've had in the past is writing mysql plugins.
> >>
> >> I help maintain an image processing library, and one use of the
> >> library was a mysql plugin that added query-by-image-content. To
> get
> >> the plugin working we had to make sure we could run threadless.
> >
> > By threadless, do you mean not linking to the thread library, or do
> you
> > mean "don't spawn threads". Because initializing threads doesn't
> mean
> > we'll create threads, just that we make global us data threadsafe.
>
> Sorry, I wasn't clear. You mustn't even link to pthreads when building
> mysql plugins.
>
> Or that used to be the case anyway. I tried a quick google but
> couldn't find anything saying whether or not this was still a problem,
> so this might all be a red herring anyway.

I guess this is the same problem that we had recently, where its not
allowed to dynamically link in libpthreads in a binary that doesn't link
to libpthreads.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc
       [hidden email]            [hidden email]
He's an underprivileged ninja vampire hunter searching for his wife's true
killer. She's a transdimensional nymphomaniac mermaid with the power to bend
men's minds. They fight crime!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Colin Walters
In reply to this post by Alexander Larsson
On Wed, Dec 2, 2009 at 11:03 AM, Alexander Larsson <[hidden email]> wrote:

>
> Running with this patch i ran into an issue while building gnome-shell:
>
>  GEN    Gdm-1.0.gir
>
> GThread-ERROR **: GThread system may only be initialized once.
> aborting...
> Command '['/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/Gdm-1.0',
> '--introspect-dump=/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/types.txt,/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/dump.xml']' returned non-zero exit status -5
>
> Not sure exactly what crashed, but obviously something ran:
> g_type_init() and then g_thread_init(). Maybe we need to make this a
> non-fatal warning?

Nah, just a bug in the dumper.  Fixed:

commit ffd9b39620c9665a8685363202b4f02fa895288c
Author: Colin Walters <[hidden email]>
Date:   Wed Dec 2 12:56:52 2009 -0500

    [dumper] Fix threads initialization

    Correctly guard with g_thread_supported, call g_thread_init before
    g_type_init.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Alexander Larsson
On Wed, 2009-12-02 at 18:01 +0000, Colin Walters wrote:

> On Wed, Dec 2, 2009 at 11:03 AM, Alexander Larsson <[hidden email]>
> wrote:
> >
> > Running with this patch i ran into an issue while building
> gnome-shell:
> >
> >  GEN    Gdm-1.0.gir
> >
> > GThread-ERROR **: GThread system may only be initialized once.
> > aborting...
> > Command '['/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/Gdm-1.0',
> >
> '--introspect-dump=/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/typ
> es.txt,/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/dump.xml']'
> returned non-zero exit status -5
> >
> > Not sure exactly what crashed, but obviously something ran:
> > g_type_init() and then g_thread_init(). Maybe we need to make this a
> > non-fatal warning?
>
> Nah, just a bug in the dumper.  Fixed:

This particular instance is fixed, but there can be a lot more out
there. Why force every app to add this check when we could do it
ourselves.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc
       [hidden email]            [hidden email]
He's a genetically engineered neurotic boxer with a robot buddy named Sparky.
She's a warm-hearted out-of-work advertising executive with someone else's
memories. They fight crime!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Colin Walters
On Wed, Dec 2, 2009 at 8:38 PM, Alexander Larsson <[hidden email]> wrote:
>
> This particular instance is fixed, but there can be a lot more out
> there. Why force every app to add this check when we could do it
> ourselves.

I'm not objecting to defaulting to working around this bug; it's
certainly possible other applications do it.  However the docs are
pretty clear on how to call g_thread_init, and I was doing it wrong =)
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Adam Goode-4
In reply to this post by Alexander Larsson
> I'll start with the proposal and then explain the reasons for it:

>
> Starting with next glib release:
> * libgobject links to libgthread
> * g_type_init() starts with:
>
> #ifdef G_THREADS_ENABLED
>  if (g_thread_supported())
>    g_thread_init (NULL);
> #endif
>
> This means that everything above gobject can rely on thread primitives
> being availible, and that global stuff in glib (mainloop, gslice,
> globals, etc) are threadsafe.
Will this enable my library that uses only GSlice to be used from
non-GLib-aware applications that use different threads?

Specifically, I have a library that internally uses GSlice and
GHashTable, but I don't expose any GLib details. I link my library with
Java and other applications that use pthreads. Will this make GSlice
work OK? How can I avoid calling g_thread_init() from within my library?



Thanks,

Adam


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Enable threads by default

Andrew Cowie
On Sat, 2009-12-05 at 19:45 -0500, Adam Goode wrote:
> Specifically, I have a library that internally uses GSlice and
> GHashTable, but I don't expose any GLib details. I link my library with
> Java and other applications that use pthreads.

In the java-gnome library (the Java language bindings to GTK and other
GNOME libraries), we call g_thread_init() and gdk_threads_init().
Everything works fine [ie, programs with their UI written in java-gnome
work fine]

AfC
Sydney

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (204 bytes) Download Attachment
12