On Thu, Nov 12, 2009 at 7:52 PM, Alexander Larsson wrote:
> On Tue, 2009-11-10 at 18:22 -0600, Stef Walter wrote:
>> Emmanuele Bassi wrote:
>> > 1. bug 600141 (desrt)
>> > - dbus-1 brings in pthread
>> > - gio-2.0 doesn't
>> > - dlopen()-ing a shared object linking to pthread from a library
>> >
On Thu, Nov 12, 2009 at 20:52, Alexander Larsson wrote:
> On Tue, 2009-11-10 at 18:22 -0600, Stef Walter wrote:
>> Emmanuele Bassi wrote:
>> > 1. bug 600141 (desrt)
>> > - dbus-1 brings in pthread
>> > - gio-2.0 doesn't
>> > - dlopen()-ing a shared object linking to pthread from a library
>> > t
On Tue, 2009-11-10 at 11:13 +, Raja Mukherji wrote:
> I have a problem
No doubt.
But you're on the wrong list. Use gtk-list to ask questions about
developing *with* the library. This mailing list is for people hacking
*on* the library.¹
> where I have to call gtk code, including two
> gtk_
Hi
I want to make a small break to the API of GDataInputStream.
The details are in bug #584284.
https://bugzilla.gnome.org/show_bug.cgi?id=584284
The summary:
When I implemented the async versions of read_line() and read_until() I
got the semantics of the read_until_async() function very slig
On Tue, 2009-11-10 at 18:22 -0600, Stef Walter wrote:
> Emmanuele Bassi wrote:
> > 1. bug 600141 (desrt)
> > - dbus-1 brings in pthread
> > - gio-2.0 doesn't
> > - dlopen()-ing a shared object linking to pthread from a library
> > that doesn't is a big no-no which kind of works in Linux but
> >
On Thu, 2009-11-12 at 16:12 +0100, Christian Dywan wrote:
> Am Thu, 12 Nov 2009 09:55:34 -0500
> schrieb Ryan Lortie :
>
> > On Thu, 2009-11-12 at 14:57 +0100, Alexander Larsson wrote:
> > > One issue with this change is that it sort of breaks the whole
> > > reason for having libgthread in a sepa
On Thu, 2009-11-12 at 16:45 +0100, Stanislav Brabec wrote:
> I think that gmodule-2.0.pc is the best place to add needed fix, as
> loading of threaded modules is the main originator of all these
> problems.
I agree, this seems to be solving the issue at the correct place.
If someone has super-ti
On 11/12/2009 11:36 AM, Michael Meeks wrote:
> The 'real' fix, is to recognise that:
>
> a) interposing (excluding LD_PRELOAD) is a horrible expensive
> feature, that more often than not causes problems
Well, you're talking about the specific thing that (presumably) is
causin
On Thu, 2009-11-12 at 16:36 +, Michael Meeks wrote:
> b) there are simple, more robust ways to indirect the 250 or so
> method calls that are thread sensitive via a single vtable
Hmm, so - having written all that nonsense - I read the glibc code; and
incredibly it does
Hi there,
On Thu, 2009-11-12 at 16:45 +0100, Stanislav Brabec wrote:
> > On Thu, 2009-11-12 at 14:04 +0100, Stanislav Brabec wrote:
> > > Other possibilities:
> > > - Cleanly say, that dynamic loading of modules linked with libpthread is
> > > not recommended.
> > This would definitely be the nice
On Thu, 2009-11-12 at 14:57 +0100, Alexander Larsson wrote:
> On Wed, 2009-11-11 at 23:10 -0500, Ryan Lortie wrote:
>
> > The easiest fix here is to link libgio with -pthread. We discussed this
> > at the GTK meeting yesterday and decided to do this unless anyone on the
> > list has a compelling
On Thu, 2009-11-12 at 09:55 -0500, Ryan Lortie wrote:
> On Thu, 2009-11-12 at 14:57 +0100, Alexander Larsson wrote:
> > One issue with this change is that it sort of breaks the whole reason
> > for having libgthread in a separate library.
>
> Ben has indicated that he thinks that by 3.0 threading
Ryan Lortie wrote:
> On Thu, 2009-11-12 at 14:04 +0100, Stanislav Brabec wrote:
> > Other possibilities:
> > - Cleanly say, that dynamic loading of modules linked with libpthread is
> > not recommended.
> This would definitely be the nicest solution, but I doubt that it is
> possible.
I guess that
Am Thu, 12 Nov 2009 09:55:34 -0500
schrieb Ryan Lortie :
> On Thu, 2009-11-12 at 14:57 +0100, Alexander Larsson wrote:
> > One issue with this change is that it sort of breaks the whole
> > reason for having libgthread in a separate library.
>
> Ben has indicated that he thinks that by 3.0 thread
On Thu, 2009-11-12 at 14:57 +0100, Alexander Larsson wrote:
> One issue with this change is that it sort of breaks the whole reason
> for having libgthread in a separate library.
Ben has indicated that he thinks that by 3.0 threading should be
non-optional in all glib applications on the premise t
On Thu, 2009-11-12 at 14:04 +0100, Stanislav Brabec wrote:
> Other possibilities:
> - Cleanly say, that dynamic loading of modules linked with libpthread is
> not recommended.
This would definitely be the nicest solution, but I doubt that it is
possible.
Cheers
_
On Thu, 2009-11-12 at 00:27 -0500, Behdad Esfahbod wrote:
> > libdbus links against libpthread.
>
> My only question is: can't this be fixed instead? I don't immediately see
> why not..
dbus has a threading abstraction layer just like glib does. The
difference between dbus and glib is that db
On Wed, 2009-11-11 at 23:10 -0500, Ryan Lortie wrote:
> The easiest fix here is to link libgio with -pthread. We discussed this
> at the GTK meeting yesterday and decided to do this unless anyone on the
> list has a compelling reason not to.
Its certainly an easy fix. However, it will inflict e.
On Wed, 2009-11-11 at 09:33 +0100, Thiago Macieira wrote:
> Actually, it does.
>
> There's a performance penalty in loading each library, plus a combined
> penalty
> of symbol resolution. Remember that each library has a different symbol
> resolution search order, so the dynamic linker needs t
Behdad Esfahbod wrote:
> On 11/11/2009 11:10 PM, Ryan Lortie wrote:
>
> > libdbus links against libpthread.
>
> My only question is: can't this be fixed instead? I don't immediately see
> why not..
The problem is much deeper - in the ELF format and it is not a bug. ELF
features interposing -
On 11/11/2009 08:10 PM, Ryan Lortie wrote:
> libdbus links against libpthread.
Hmm:
$ ldd /usr/lib/libdbus-1.so.3.4.0
linux-vdso.so.1 => (0x7fff8ebff000)
libc.so.6 => /lib/libc.so.6 (0x00350100)
/lib64/ld-linux-x86-64.so.2 (0x0034ffa0)
Although:
$ n
21 matches
Mail list logo
