Problems with the new file selector and non-threaded
Joe Marcus Clarke
marcus at FreeBSD.org
Fri Apr 23 01:20:57 GMT 2004
On Wed, 2004-04-21 at 22:38, Jeremy Messenger wrote:
> > 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.
> > 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..>
> > Thanks for listening.
> > Joe
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome at FreeBSD.org
FreeNode / #freebsd-gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20040422/6fd4afbd/attachment.bin
More information about the freebsd-gnome