Problems with the new file selector and non-threaded applications

[Joe Marcus Clarke]

On Wed, 2004-04-21 at 22:38, Jeremy Messenger wrote:

[snip]

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

I lied, this does not work.  It looked like it worked, but in fact, the
gtk+ file selector was used since there were undefined pthread symbols.

> 
> All the others(2,3,4,5)' Cons don't look good, I think they will hurt more.

I think 2 might be our best bet.  There's also a modified 2 we can
consider, where we explicitly add PTHREAD_LIBS to all non-threaded ports
that invoke the file selector.  This could be done reactively once
people start reporting crashes.  Or, we could combine 2 and 3 so we
wouldn't get a crash, but people could see a warning, send email, and we
could then link the app to PTHREAD_LIBS.

Joe

> 
> > 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
-- 
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/20040422/6fd4afbd/attachment.bin