Date: Thu, 21 Jan 1999 12:38:14 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: Jeremy Lea <reg@shale.csir.co.za> Cc: freebsd-current@FreeBSD.ORG, Julian Elischer <julian@whistle.com>, Peter Wemm <peter@netplex.com.au> Subject: Re: Using LinuxThreads Message-ID: <19990121123814.B5495@tar.com> In-Reply-To: <19990121181228.A98581@shale.csir.co.za>; from Jeremy Lea on Thu, Jan 21, 1999 at 06:12:29PM %2B0200 References: <19990118182717.A15566@top.worldcontrol.com> <Pine.BSF.4.05.9901182203500.11971-100000@janus.syracuse.net> <19990119024539.A88383@top.worldcontrol.com> <19990119140613.B826@shale.csir.co.za> <19990119091151.F600@tar.com> <19990121181228.A98581@shale.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 21, 1999 at 06:12:29PM +0200, Jeremy Lea wrote: > On Tue, Jan 19, 1999 at 09:11:51AM -0600, Richard Seaman, Jr. wrote: > > Actually, the new version, in FreeBSD "ports" form, doesn't require > > -DLINUXTHREADS anymore, but it does require -I/usr/local/include to > > pick up the right header, since it installs a pthread.h into > > /usr/local/include. This conflicts with the pthread.h in /usr/include. > > This is nagging at me. Having two headers of the same name, but importantly > different content is asking for touble. There needs to be a way to ensure > that only one or the other is picked up. The best way I can think of is to > only include the contents of the user thread pthread.h if _THREAD_SAFE is > defined (to force people to use the right defines...) and the contents of > kernel thread pthread.h if _REENTRANT (and not _THREAD_SAFE) is defined. > This has the added bonus of meaning that most linux apps wont have to be > patched. Actually, its more complicated than this. Currently, _THREAD_SAFE is a switch for turning on libc_r behaviour when compiling libc_r, but it is a switch for more general thread safe behaviour in the header files for libc and libc_r. In other words, threaded applications linking against either libc or libc_r should define _THREAD_SAFE. But, when compiling libc, _THREAD_SAFE should be turned off. Very confusing IMHO. Now, on the topic of conflicting pthread.h files, I agree this is a problem. One choice, which I originally implemented, is to fix pthread.h so it pulls in the right data based on a swtich (eg. if LINUXTHREADS is defined, pull in LT headers, else pull in user threads headers). I don't like using _THREAD_SAFE for this test, for the reason mentioned above. And I don't like using _REENTRANT because its so widely used and it could still confure people. The second choice, which is what the current version of the "port" does, is to put the conflicting headers in different directories, and require the application to define the order of the include files to get the right one in. There are proglems either way, and I don't really prefer one over the other. > To many applications have configure scripts which might find > /usr/local/lib/libpthread, but not /usr/local/include/pthread.h, or find > /usr/lib/libc_r and find /usr/local/include/pthread.h. Yes. This is a problem. But, taking glib as an example, and using glib-1.1.13 directly (not the "port", which is kind of messed up for linuxthreads), the following configure script does the right thing: $ CPPFLAGS="-D_THREAD_SAFE -I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure --with-threads=posix This isn't that bad, and I think you need to customize your configure scripts (normally) if you're using threads, anyway. > What are the plans for the import of the LinuxThreads stuff into the src > tree? Or is it going to remain a port, and the source tree position be > reserved for a future kernel threads implementation? My mind says it is to > closely tied to the OS to be a port. It can be a port. I suspect there will be more support for its possible inclusion this way. The current version at lt.tar.com is in ports form. Granted, it depends to an unusual degree (for a port) on having the src tree around. > And when are COMPAT_LINUX_THREADS and VM_STACK going away? I have no idea. I was hoping that at least COMPAT_LINUX_THREADS would go away before the branch. I don't have commit authority, so it isn't up to me. -- Richard Seamman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990121123814.B5495>