On Fri, 15 Aug 2008, Christian Dywan wrote:
I think both is rather open for missunderstandings actually, before and
after the improvement of the g_thread_init documentation.
g_mem_set_vtable clearly asserts that it must be called *before
anything else* and so does g_thread_init.
There is no amb
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
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 f
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
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 somethi
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_vtab
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 always
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 t
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 automa
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 i
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 are you talking about ?
___
gtk-devel-list mailing list
gtk-d
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):
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
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.
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
>>
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() document
> "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, i
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 s
> 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 g_thr
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 g_t
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 m
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 term "threaded GLib program" here is very vague. What it
efffectively means, to the best of my knowledge, is "a progra
22 matches
Mail list logo
