Date: Wed, 21 Apr 2004 01:22:18 -0400 From: Joe Marcus Clarke <marcus@FreeBSD.org> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Help: threading problem in non-threaded applications Message-ID: <1082524938.41182.26.camel@shumai.marcuscom.com> In-Reply-To: <Pine.GSO.4.10.10404201652240.14017-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10404201652240.14017-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-akjjKJEg+CZ8tCZxwMlk
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Tue, 2004-04-20 at 17:08, Daniel Eischen wrote:
> On Tue, 20 Apr 2004, Joe Marcus Clarke wrote:
>=20
> > I have a problem I'm hoping someone can help me with. GTK+ 2.4
> > introduced a new file selection GUI which works just fine in threaded
> > and non-threaded applications. However, GNOME 2.6 augmented this dialo=
g
> > with a dynamically loadable threaded shared object. The GNOME version
> > is automatically used by all GTK+ apps when run under a GNOME desktop i=
f
> > libgnomeui is installed.
>=20
> Shared libraries shouldn't link with threading libraries
> unless they actually create threads behind the scenes.
> Actually, even so, they could force the (unthreaded)
> applications that link with them to explicitly supply
> the thread library in the link option.
And that's the case here. The underlying libraries are creating and
using threads. But what happens when a non-threaded application loads a
thread library via dlopen() (which is the case here)? Here's the stack
trace I see:
#1 0x28b474b5 in _spinlock_debug () from /usr/lib/libc_r.so.5
No symbol table info available.
#2 0x28b4c873 in _mutex_cv_lock () from /usr/lib/libc_r.so.5
No symbol table info available.
#3 0x28b4c738 in _mutex_cv_unlock () from /usr/lib/libc_r.so.5
No symbol table info available.
#4 0x28b50e50 in _pthread_cond_wait () from /usr/lib/libc_r.so.5
No symbol table info available.
#5 0x28b50fa0 in pthread_cond_wait () from /usr/lib/libc_r.so.5
No symbol table info available.
#6 0x288af4e3 in pthread_cond_wait () from /lib/libc.so.5
No symbol table info available.
#7 0x28a00262 in giop_recv_buffer_get (ent=3D0xbfbfd9d0)
at giop-recv-buffer.c:707
tdata =3D (GIOPThread *) 0x8090320
...
Under normal circumstances, this application doesn't need to be linked
to PTHREAD_LIBS. However, for this one option (--file-selection in this
case), a threaded module is dlopen()'d, and this happens.
[snip]
> Try using -pthread to build the shared library instead of
> -lpthread. That will avoid the link to libpthread. If
> it's only locking that the library needs, libc should have
> all the necessary stubs.
It's more than just locking. Threads are being created. If I go with
-pthread, I'd have to relink every GNOME application, and I'm trying to
avoid that if possible.
Joe
>=20
> An alternative is to get GNOME maintainers to use a thread
> stub library and have their shared libraries link to that.
> The stub library would provide weak locking symbols and
> be overridden by applications bringing in real thread
> libraries. Perhaps something like that could work.
--=20
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
--=-akjjKJEg+CZ8tCZxwMlk
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQBAhgUJb2iPiv4Uz4cRAnlEAJ44ASsdlSyM3YMHH0P7jM8wU2a5EgCbBbaX
hX4yziGiOc1Po7xKaSi1syE=
=Pnq2
-----END PGP SIGNATURE-----
--=-akjjKJEg+CZ8tCZxwMlk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1082524938.41182.26.camel>