Re: Kernel threads availability

Adrian Chadd wrote:

> Nope. The project fell into decay because people wanted a better way
> of kernel threads. I'm pretty sure that you can compile and run FreeBSD
> binaries using the linuxthreads code without needing to invoke the
> Linux syscall emulation.

Yep. Took a quick peek at the current status and it looks hopeful.
However, the FreeBSD libc isn't fully linuxthreads safe yet so you might
run into trouble there if more than one thread calls libc functions.
Attached is a small README which describes the package status.

/Henrik

Some brief notes:

1) This package is intended to run on FreeBSD 5.0-current or
FreeBSD 4.X i386 processors only.

Compile your applications that use LinuxThreads with the following
command line options:

  -D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -llthread -llgcc_r

Note that the include (-I<path>) directive shown here should appear before any
other include directive that would cause the compiler to find the FreeBSD file
/usr/include/pthread.h. Using the FreeBSD pthread.h instead of the linuxthreads
pthread.h will result in an app fails fails in many odd and maybe spectacular
ways.

In order to facilitate porting applications which expect a libpthread, you can
create the following symlinks if you want:

  ln -s /usr/local/lib/liblthread.a /usr/lib/libpthread.a
  ln -s /usr/local/lib/liblthread_p.a /usr/lib/libpthread_p.a
  ln -s /usr/local/lib/liblthread.so.2 /usr/lib/libpthread.so.2
  ln -s /usr/local/lib/liblthread.so.0 /usr/lib/libpthread.so
  /sbin/ldconfig -m /usr/lib

If you do this, you can instead use:

  -D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -lpthread -llgcc_r
or
  -D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -kthread -llgcc_r

Do not use libc_r with LinuxThreads, and do not compile/link with the -pthread
option (which pulls in libc_r). Rather, link with libc (which you will get by
default).

2) You should consider enabling the posix priority extensions in your kernel.
Adding the following to your kernel config file before you execute config and
before you re-make the kernel should suffice.

options "P1003_1B"
options "_KPOSIX_PRIORITY_SCHEDULING"
options "_KPOSIX_VERSION=199309L"

These options are not mandatory.

3) If you plan on having lots of threads, check the sysctl value of
kern.maxproc. Each kernel thread counts against maxproc. You can increase
maxproc by changing the MAXUSERS value in your kernel config file. maxproc is
set at 20 + 16 * MAXUSERS.

4) Be aware of the following libc issues:

  a) Not all libc calls are thread safe. In particular gmtime, localtime, etc
  are not thread safe. In general, where the pthreads spec calls for "_r"
  functions, these are either not provided, or if provided are not thread safe
  (in most cases) and the related libc calls are not thread safe. This differs
  somewhat from the FreeBSD libc_r library, where some, but not all, of these
  functions are both thread safe and have "_r" versions.

  b) Not all of the libc calls that are supposed to be cancellation points are
  implemented as such. While linux threads has the cancel functions
  implemented, deferred cancellation will not work as required by POSIX
  1003.1c-1995, since the co-operation needed from libc is not complete.

5) Known problems and issues:

  It is possible that the instructions given above for including liblgcc_r
  are not sufficent. liblgcc_r is a version of libgcc_r linked against this
  linuxthreads package. It is intended that applications link against this,
  rather than libgcc_r (which is linked against libc_r) or libgcc (which is not
  thread safe).

  The normal gcc link options cause libgcc to be included twice in the link line
  (and libgcc_r twice when linking with the -pthread option). It is therefore
  possible that a custom link line needs to be generated that specifically
  excludes the default libgcc and which includes liblgcc_r twice. There are no
  known problems resulting from the link procedure suggested above. However,
  compiling/linking with the "-v" option will illustrate the issue, where libgcc
  is included twice in addition to liblgcc_r.
Received on Wed Jun 14 2000 - 00:12:58 MDT