Re: Stupid question regarding g_thread_init() and gtk_threads_init()
- From: "NavEcos" <ecos navosha com>
- To: "Arnaud Charlet" <charlet ACT-Europe FR>, "Sven Neumann" <sven gimp org>
- Cc: gtk-list gnome org
- Subject: Re: Stupid question regarding g_thread_init() and gtk_threads_init()
- Date: Tue, 27 Jul 2004 18:37:15 -0700
----- Original Message -----
From: "Sven Neumann" <sven gimp org>
To: "Arnaud Charlet" <charlet ACT-Europe FR>
Cc: "NavEcos" <ecos navosha com>; <gtk-list gnome org>
Sent: Tuesday, July 27, 2004 3:47 AM
Subject: Re: Stupid question regarding g_thread_init() and
gtk_threads_init()
> Hi,
>
> Arnaud Charlet <charlet ACT-Europe FR> writes:
>
> > > If gdk_thread_init() would call g_thread_init() you couldn't use GTK+
> > > with another library or any code that needs to call g_thread_init()
> > > before gtk_init(). Doesn't sound like a good idea to me.
> >
> > That's misleading: gdk_thread_init would call g_thread_init if not
> > already done (it already checks whether g_thread_init has been
> > called), so that doesn't prevent you from calling g_thread_init
> > before hand, possibly with different arguments.
> >
> > As for not being able to use GTK+ with another library that's not a
> > valid argument: Gdk depends on glib already for many things, so the
> > dependency is there, and can't be removed.
>
> I wasn't talking about removing the dependency. But you might want to
> use glib, gtk+ _and_ some other library using GThreads.
In which case, why doesnt gdk_thread_init() call g_thread_init()?
Or why doesn't, say, gdk_threads_enter() say with an ASSERT "hey stupid: I
noticed that g_thread_init() was never called".
I don't want to sound like a little brat here since I really like GTK and I
really appreciate that it's available to me, but I think a couple slight
modifications would go a long way into making GTK a lot easier to use.
GtkInitForStupidPeople (bool bEnableThreads) or something, where it does
everything for you - as a convenience function would be great. I know you
can use different contexts and stuff like that, but the reality is that only
a handful of people do. Why not make a "duh" interface? Let's face it, I'm
just totally stupid, and being very dumb, I like simple interfaces. Simple
interfaces prevent dumb people like me from filling up lists with stupid
questions like this, and it reduces bugs too.
> > Now, I'm sure there must be *some* valid reason for not doing the
> > obvious, but I don't see what this reason would be (and don't see it
> > documented as part of e.g. gdk_threads_init).
>
> Well, perhaps the reason is simply that gdk_threads_init() is so
> rarely used since it is in general a bad idea to have multiple threads
> access the user interface.
I've got an application that is fed data asynchronously independant of user
intervention to display real time data. I'm well versed in embedded
programming and am comfortable with dealing with race conditions. Threads
are very useful, if you know how to exploit them. In my world (at least)
the "proper" way to do two tasks which are completely independant of the
other except that they share data is to use two threads.
> But you could of course file a bug report and ask to have
> gdk_threads_init() changed.
It's just a design question. I thought "hmm, I must be missing something
here - there must be a very rational reason for doing this." So I asked.
That's all.
-Rich
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]