libcaps in

Matt Dillon has added in a new ‘libcaps’ library, mostly for experimentation, which appears to be the base for userland threading.

Post quoted:

“Ok, I’ve committed a new library, libcaps. This library is intended
to encompass core userland threading features and IPC mechanisms.
It currently contains an (incomplete) lwkt_thread.c, a more complete
lwkt_msgport.c (both inherited from the kernel), an untested slab
allocator ported from the kernel (it was easier to port then inherit),
and my initial go at IPC functions which are the caps_*.c files.
It is not intended to become a new libcr. Instead it is intended to
abstract mechanisms that libcr will wind up using.

The new library is intentionally NOT hooked into buildworld. It is also
quite messy and incomplete at the moment, but works well enough to run
the IPC test program I commited to /usr/src/test/caps.

To run the IPC test program you need to create the appropriate directory
infrastructure and make and install libcaps on a freshly installworld’d
DragonFly system.

mkdir /var/caps
mkdir /var/caps/root
cd /usr/src/lib/libcaps
make; make install
cd /usr/src/test/caps

as root: /tmp/caps1 -s in one window and /tmp/caps1 -c in
another window.

This code is intended primarily for David Rhodus and Galen Sampson.
David is going to be playing around with IPC and Galen has been working
on userland threading.

Galen: there are a lot of pieces missing in the userland threading part
of it. e.g. it’s missing the assembly switch functions, the globaldata
is hacked, and curthread returns NULL :-). It needs help!

David: the library abstracts and demonstrates the IPC concept I’ve
been talking about. The only real concept problem is that at the moment
the client cannot wait on its reply port for the message reply (because
the threading support hasn’t been added yet). The test program uses
a hacked library call to wait for message replies. The library is
based on unix domain sockets and KQUEUE (and so can handle multiple
connections and blockages without deadlocking the service). It has not
been well tested and there are almost certainly bugs, but the basics
do work.

The IPC mechanism is fairly complex due to having to go through a non
optimal unix domain socket. Eventually the IPC mechanism will be moved
into the kernel.”