Date: Wed, 21 Apr 2004 12:52:03 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Joe Marcus Clarke <marcus@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Help: threading problem in non-threaded applications Message-ID: <Pine.GSO.4.10.10404211242070.4354-100000@pcnet5.pcnet.com> In-Reply-To: <1082564941.845.6.camel@gyros>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Apr 2004, Joe Marcus Clarke wrote: > On Wed, 2004-04-21 at 09:18, Daniel Eischen wrote: > > On Wed, 21 Apr 2004, Joe Marcus Clarke wrote: > > > > > 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: > > > > In that case you're going to have to link the application > > to a threads library. > > I had another thought based on your comments. Since -pthread does the > right thing in -CURRENT, why don't we make that the default > PTHREAD_LIBS? Why do we explicitly link to -lpthread when that causes > shared libs to be linked to threading libraries? If we did -pthread > universally, this problem would go away because ORBit would do the right > thing in the non-threaded case. I thought your example above was creating threads behind the scenes (in the library). That would either require linking the library with -lpthread or every application that used it with -lpthread. Actually, if the library is dynamically loaded, then you still need to explicitly link the application with the threads library (or else libc is going to get confused). I think most of the problem is that our synchronization types are private to each threads library. For FreeBSD-6, we'll change that and have the synchronization types uniformly defined so that libc can see them the same way that the threads library sees them. Perhaps pthread_t will also have to be uniformly defined. So a mutex initialized by libc can be used by libpthread... I don't have a problem with PTHREAD_LIBS being changed to -pthread. I don't know if that will actually solve your particular problem, but it would probably solve other problems and make it easier to mix'n match thread libraries with applications that use the same shared libraries. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10404211242070.4354-100000>