On Fri, 15 Aug 2008 10:58:59 +0300 Tor Lillqvist wrote:
The documentation for g_thread_init() says (in the stable branch):
You must call g_thread_init() before executing any other GLib
functions in a threaded GLib program.
[..]
The real use case reported on gtk-list looked much more
On Fri, Aug 15, 2008 at 11:51 AM, Brian J. Tarricone [EMAIL PROTECTED] wrote:
Yes to that last bit. If it really truly does matter that
g_thread_init() be called before other glib functions, then no *library*
should *ever* call g_thread_init(). If a library needs it, it should
check
For example, Glib have g_mem_set_vtable() that alose requires to be first.
Whee, so GLib documentation is internally inconsistent then. What a mess.
Current wording of the g_thread_init() documentation doesn't
introduces such ambiguility at least...
It doesn't? I think You must call
On Fri, 2008-08-15 at 15:45 +0300, Tor Lillqvist wrote:
For example, Glib have g_mem_set_vtable() that alose requires to be first.
Whee, so GLib documentation is internally inconsistent then. What a mess.
Current wording of the g_thread_init() documentation doesn't
introduces such
If your program uses threads (or other libraries that use threads),
then you must call g_thread_init() before calling any other GLib
function
It's not using threads that is the key point here. Calling
g_thread_init() is. That already changes some GLib functions to work
in different ways,
Am Fri, 15 Aug 2008 15:45:29 +0300
schrieb Tor Lillqvist [EMAIL PROTECTED]:
For example, Glib have g_mem_set_vtable() that alose requires to be
first.
Whee, so GLib documentation is internally inconsistent then. What a
mess.
Current wording of the g_thread_init() documentation doesn't
On Fri, Aug 15, 2008 at 3:45 PM, Tor Lillqvist [EMAIL PROTECTED] wrote:
For example, Glib have g_mem_set_vtable() that alose requires to be first.
Whee, so GLib documentation is internally inconsistent then. What a mess.
Current wording of the g_thread_init() documentation doesn't
introduces
On Fri, 2008-08-15 at 16:05 +0300, Tor Lillqvist wrote:
If your program uses threads (or other libraries that use threads),
then you must call g_thread_init() before calling any other GLib
function
It's not using threads that is the key point here. Calling
g_thread_init() is. That
On Fri, 2008-08-15 at 10:58 +0300, Tor Lillqvist wrote:
The documentation for g_thread_init() says (in the stable branch):
You must call g_thread_init() before executing any other GLib
functions in a threaded GLib program.
Is there a good reason to not compile separate threaded and
Also, is there any specific reason *not* to call g_thread_init() in glib's
init routine by default anyway? Any penalties?
2008/8/15 Patrick Hallinan [EMAIL PROTECTED]
On Fri, 2008-08-15 at 10:58 +0300, Tor Lillqvist wrote:
The documentation for g_thread_init() says (in the stable branch):
I meant a function marked with the constructor attribute.
2008/8/15 Matthias Clasen [EMAIL PROTECTED]
2008/8/15 Milosz Derezynski [EMAIL PROTECTED]:
Also, is there any specific reason *not* to call g_thread_init() in
glib's
init routine by default anyway? Any penalties?
What init routine
I'd argue mandatory init functions are more or less always wrong, they
all train-wreck in a similar way ... unfortunately every G-inspired
library seems to gratuitously have them.
If the init function has no args, then it should be possible for the
library to just deal with it and call it
I forgot g_thread_init takes args, so nvm the constructor version.
2008/8/15 Havoc Pennington [EMAIL PROTECTED]
I'd argue mandatory init functions are more or less always wrong, they
all train-wreck in a similar way ... unfortunately every G-inspired
library seems to gratuitously have them.
Havoc Pennington wrote:
If the init function does have arguments, then you end up with a
requirement that all libraries and modules calling it must call it
with the same args ... which isn't possible ... so init functions with
arguments are broken unless the *app* and never a library will
Am Freitag, den 15.08.2008, 15:06 +0200 schrieb Christian Dywan:
Am Fri, 15 Aug 2008 15:45:29 +0300
schrieb Tor Lillqvist [EMAIL PROTECTED]:
I think both is rather open for missunderstandings actually, before and
after the improvement of the g_thread_init documentation.
g_mem_set_vtable
Hi,
On Fri, Aug 15, 2008 at 5:55 PM, Brian J. Tarricone [EMAIL PROTECTED] wrote:
This breaks for libraries that require locking in threaded programs but
(obviously) not in non-threaded programs. You can get into a situation
where you call a lock() without threads initialised, then something
On Fri, 2008-08-15 at 01:51 -0700, Brian J. Tarricone wrote:
On Fri, 15 Aug 2008 10:58:59 +0300 Tor Lillqvist wrote:
... Should ORBit2 g_error() out if
it notices that it wants to use threads but g_thread_init() has not
been called, instead of calling it itself?
Yes to that last bit. If
On Fri, 2008-08-15 at 19:09 +0200, Milosz Derezynski wrote:
Also, is there any specific reason *not* to call g_thread_init() in
glib's init routine by default anyway? Any penalties?
As was pointed out, there's no GLib init routine, but from the
standpoint of a prominent library that we use a
2008/8/16 Andrew Cowie [EMAIL PROTECTED]:
[...]
At the very least across the rest of the GNOME stack, but if it's a
behaviour change we want to encourage not just there but beyond, I
wonder how could we go about incenting library authors to adopt this
pattern?
I would expect an author of a
19 matches
Mail list logo
