From owner-freebsd-gnome@FreeBSD.ORG Thu Apr 22 18:20:57 2004 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EC0416A4CE for ; Thu, 22 Apr 2004 18:20:57 -0700 (PDT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id C65C043D54 for ; Thu, 22 Apr 2004 18:20:56 -0700 (PDT) (envelope-from marcus@FreeBSD.org) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i3N1Jfwx016986; Thu, 22 Apr 2004 21:19:41 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Jeremy Messenger In-Reply-To: References: <1082595788.34974.23.camel@shumai.marcuscom.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ajJhgtUH7Lk9OtIPlf1c" Organization: FreeBSD, Inc. Message-Id: <1082683244.28653.20.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 22 Apr 2004 21:20:45 -0400 cc: FreeBSD GNOME Users Subject: Re: Problems with the new file selector and non-threaded applications X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 01:20:57 -0000 --=-ajJhgtUH7Lk9OtIPlf1c Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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. >=20 > This seems to be a best solution until 6.x if nobody have any better=20 > solution. I would care less for 5.2.1 if it is going to not work, because= =20 > they should be expected since it's a new technology. I personal see no=20 > 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. >=20 > All the others(2,3,4,5)' Cons don't look good, I think they will hurt mor= e. 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 >=20 > > 2. Explicitly link all gtk+ applications that use the new file selectio= n > > 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 on= e > > 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 porte= d > > to new versions of glib. This means that non-threaded applications wil= l > > 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. >=20 > Have anyone seen PHY's fund? Amazing! Perhaps, threads team need one like= =20 > this to get it in 5.x; not 6.x? :-) >=20 > Cheers, > Mezz >=20 > > Thanks for listening. > > > > Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-ajJhgtUH7Lk9OtIPlf1c Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAiG9sb2iPiv4Uz4cRApATAJ4piPkaW2XQBLAXZLtZfyCRt/sD9gCdEt36 A1TkcHYZ+oTDsWOjjcABQQw= =6w0K -----END PGP SIGNATURE----- --=-ajJhgtUH7Lk9OtIPlf1c--