Help: threading problem in non-threaded applications

[Joe Marcus Clarke]

On Tue, 2004-04-20 at 17:08, Daniel Eischen wrote:
> On Tue, 20 Apr 2004, Joe Marcus Clarke wrote:
> 
> > 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 dialog
> > with a dynamically loadable threaded shared object.  The GNOME version
> > is automatically used by all GTK+ apps when run under a GNOME desktop if
> > libgnomeui is installed.
> 
> 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=0xbfbfd9d0)
    at giop-recv-buffer.c:707
        tdata = (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

> 
> 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.
-- 
Joe Marcus Clarke
FreeBSD GNOME Team	::	gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040421/1ec7c0f2/attachment.bin