[ Followups to -arch only please ]

I've got some changes to libc and libc_r that I'd like reviewed.
These changes eliminate the _THREAD_SAFE macro and allow a libc
and libc_r that can be linked together via -lc_r.  This also means
that -pthread and -D_THREAD_SAFE can be deprecated.  Note that
libc_r could be now be renamed libpthread, but I would like to
reserve that for KSE Project development where we might want to
have both libraries around while libpthread (using KSEs) is being
developed.

The diffs are posted at:

  http://people.freebsd.org/~deischen/libc.diffs
  http://people.freebsd.org/~deischen/libc_r.diffs

The libc diffs include src/include, src/lib/libc, as well as
src/usr.sbin/pppctl (our only threaded app) changes, whereas
the libc_r diffs are just those changes to src/lib/libc_r.

I've tested these changes with ACE, but still have other testing
that I'll be doing over the weekend.  The patches have also
survived a buildworld, but the installworld will have to wait
for this weekend.  If you try these patches make sure you save a
copy of libc.so.5 just in case...

And BTW, many thanks to John Polstra for explaining some of the
issues involved with linking :-)


Overview of the changes
-----------------------

For those not familiar with our current libc_r, it is currently
built to include a thread-safe libc as well as the POSIX threads
routines.  On the other hand, libc is built to be non-thread
safe.  This differs from other OSs and from what POSIX mandates
and means that we require non-standard hacks like the linker
option -pthread (which links to libc_r and prevents linking to
libc).

System calls that need to be wrapped (HIDDEN_SYSCALLS) are now
defined in libc/Makefile instead of libc_r/Makefile.  This means
that libc now contains:

        _thread_sys_foo - actual syscall
        _foo            - weak definition to _thread_sys_foo
        foo             - weak definition to _thread_sys_foo

I've changed all the instances of foo() to _foo() in libc for
those hidden system calls.  Anyone modifying or adding to libc
will have to be careful to use the same conventions.

In order to define the prototypes for _foo(), we introduce
namespace.h and un-namespace.h.  BDE suggested this as a way to
define the prototypes for the hidden system calls.  Use them as
follows:

        #include "namespace.h"
        #include <unistd.h>
        /* Other standard includes... */
        #include "un-namespace.h"

        /*
         * DB contains the member 'close' which is defined to
         * _close if included before un-namespace.h
         */
        #include <db.h>

        /* Other local includes... */

        int
        somelibcfunc(int fd, void *buf, size_t len)
        {
                ...
                ret = (int)_read(fd, buf, len);
                ...
                return (ret);
        }

Including namespace.h will define those hidden system calls used
within libc from foo to _foo; un-namespace.h will undefine them.
A few others are defined as well, such as _pthread_mutex_lock and
friends.  This allows libc_r to provide replacement functions for
them if it is also linked in.

One note about lib/libc/stdio/mktemp.c.  This file really wants
to use namespace.h but can't because it is used in building part
of the C compiler (or something like that; the error has long
since scrolled off my window).

There are basically only two changes to libc_r.  One is to implement
the pthread_foo() functions as _pthread_foo() and make pthread_foo
a weak definition to _pthread_foo.  This allows an application to
have it's own pthread_foo().  I noticed Solaris does this to
libpthread as well as to libc.

The other change to libc_r is to eliminate references to the
global _thread_run and replace them with a function call to get
the currently running thread (which will be needed for the KSE
project).  Yes, I could do something like errno, but that wouldn't
encourage getting the running thread once and caching it.

Comments welcome,

-- 
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to