Problems with the new file selector and non-threaded applications

[Jeremy Messenger]

On Wed, 21 Apr 2004 21:03:08 -0400, Joe Marcus Clarke <marcus at 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.