Hi, 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. 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. <Thinking> Can gcc be made to define _THREAD_SAFE automatically if -pthread is given? And _REENTRANT if -kthread is given? 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. And when are COMPAT_LINUX_THREADS and VM_STACK going away? Regards, -Jeremy -- | "In this world of temptation, I will stand for what is right. --+-- With a heart of salvation, I will hold up the light. | If I live or if I die, if I laugh or if I cry, | in this world of temptation, I will stand." -Pam Thum To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
