Problems with the new file selector and non-threaded applications

[Joe Marcus Clarke]

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.  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.

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.

Thanks for listening.

Joe

-- 
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-gnome/attachments/20040421/59fc1fd4/attachment.bin