Date: Wed, 21 Apr 2004 21:38:31 -0500 From: Jeremy Messenger <mezz7@cox.net> To: Joe Marcus Clarke <marcus@FreeBSD.org> Cc: FreeBSD GNOME Users <gnome@FreeBSD.org> Subject: Re: Problems with the new file selector and non-threaded applications Message-ID: <opr6t6yhft8ckrg5@smtp.central.cox.net> In-Reply-To: <1082595788.34974.23.camel@shumai.marcuscom.com> References: <1082595788.34974.23.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Apr 2004 21:03:08 -0400, Joe Marcus Clarke <marcus@FreeBSD.org> wrote: > Background: > ----------- > > Gtk+ 2.4 comes with a new file selector UI that can be extended with > pluggable file system modules. Libgnomeui includes such a modules that > makes use of gnome-vfs. This module is automatically used by gtk+ > applications if run under the GNOME desktop or when > gnome-settings-daemon is running (if libgnomeui is installed, that is). > > Problem: > -------- > > If a non-threaded gtk+ application calls the new file selection UI, and > the gnome-vfs file system module is loaded, that application will > immediately crash with a segmentation fault. The stack trace looks > something like: > > #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 > ... > > Non-threaded applications cannot link to or dlopen() threaded libraries > in FreeBSD 5.X. The reason is (according to eischen on hackers@): > > "I think most of the problem is that our synchronization types > are private to each threads library." > > This should be fixed in FreeBSD 6.X. I am pretty bummer with this, because it's going to be there for a very long time. > FreeBSD 4.X is not affected because it uses -pthread to link threaded > objects, and -pthread will not explicitly link libc_r to shared objects. > > Solution: > --------- > > We don't have a good one at this point. Here's what I see as possible > solutions: > > 1. Set GNOME's PTHREAD_LIBS to -pthread for all versions of FreeBSD. > _Pros:_ This should fix the problem as it will emulate what 4.X does, > and ORBit will do the right thing in the non-threaded case. _Cons:_ I > haven't tested this on 5.2.1, but it will work on -CURRENT. We will > have to relink all applications that depend on gtk20 to make this 100% > effective. This seems to be a best solution until 6.x if nobody have any better solution. I would care less for 5.2.1 if it is going to not work, because they should be expected since it's a new technology. I personal see no point of keep 5.0 and 5.1 either. All the others(2,3,4,5)' Cons don't look good, I think they will hurt more. > 2. Explicitly link all gtk+ applications that use the new file selection > UI to PTHREAD_LIBS by adding PTHREAD_LIBS to the gtk+-2.0.pc file. > _Pros:_ This will solve the problem for all dynamically loaded gtk+ > modules. _Cons:_ We will be linking otherwise non-threaded apps to > PTHREAD_LIBS. This will not fix other g_modules. > > 3. Teach gtk+ not to load a threaded file system modules into a > non-threaded application. _Pros:_ This will fix the problem at hand > with the file selector UI. This is a very surgical fix in that only one > port needs to be touched. _Cons:_ We will be introducing a gross hack > that will need to be forward-ported to new versions of gtk+. This only > helps with the file system modules. This means that non-threaded gtk+ > applications will not be able to access VFS objects through the file > selection UI (not that they could before with earlier versions of gtk+ > though). > > 4. Teach glib not to load threaded modules into non-threaded > applications. _Pros:_ This will fix the problem for all g_modules. > _Cons:_ This introduces a gross hack that will have to be forward ported > to new versions of glib. This means that non-threaded applications will > not be able to take advantage of threaded modules. > > 5. Don't configure the gnome-vfs file system for all gtk+ applications. > Instead, only do it for apps that link to libgnomeui. _Pros:_ This > should fix the problem for the file selector (though I haven't looked > into this solution much). This only affects two ports, and will not > require much nasty hacking. _Cons:_ We will still need to forward-port > our hack. This means pure gtk+ apps will not be able to access VFS > objects through the file selector. > > 6. ??? If you have a better idea, I'm all ears. I would love to > ultimately fix this problem with the least amount of nasty hacking, > while still giving users the maximum amount of functionality. Have anyone seen PHY's fund? Amazing! Perhaps, threads team need one like this to get it in 5.x; not 6.x? :-) <I am not being serious..> Cheers, Mezz > Thanks for listening. > > Joe -- bsdforums.org 's moderator, mezz.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?opr6t6yhft8ckrg5>