This is the mail archive of the
mailing list for the glibc project.
Abstracting the threads package a little better
- To: libc-alpha at sourceware dot cygnus dot com
- Subject: Abstracting the threads package a little better
- From: Corey Minyard <minyard at acm dot org>
- Date: 17 Mar 2001 16:37:02 -0600
- Reply-To: minyard at acm dot org
Andreas Jaeger asked me to forward this to this list.
I'm working on a threads package on Linux (for the reasons why, I'll
explain later), and I'm looking at the integration with glibc. Some
parts of the glibc-to-threads are nicely abstracted (errno stuff, key
stuff), some parts are not (FILE mutexes, librt, malloc mutexes). I
would like to abstract these parts a little better so I could plug in
my threads package more easily.
For FILE and malloc mutexes, I'd like to reserve a piece of memory for
the mutex (say, an area that will hold 10 pointers) and not directly
refer to the mutex type, and I'd have to remove the static
initializers and make runtime calls to initialization.
librt is a lot more complex. I don't know a lot about it, anyway. It
seems to have it's own library, and it definately requires a thread
package, so maybe the thread package should provide it's own version
of this if it is needed.
These were the only problems I saw. Am I missing anything?
Also, is this work that is valuable for general use? I'd like to
incorporate it into the main libc stuff. I have a disclaimer from my
P.S. I need a threads package that supports priority inheritance mutexes,
deadlock detection, different types of schedulers, and signal-safe
operations (any operation can be interrupted with a signal and can
safely recover, longjump out, reserve the same mutex, etc.). I
looked at modifying linuxthreads, but it looked a lot easier to
start from scratch, since the requirements touch just about
everything in the threads package.
P.P.S. Since I sent the first email, I have a first cut at the changes
required to do this. The patch is at my web page:
I have my threads package successfully integrated with glibc with
P.P.P.S. I have a patch for glibc that add flags to dlopen() that will
load the file directly into memory, not mmap the file. I need
this because we have a large system that we load incrementally,
we FTP the file to the target, load it, then delete the file.
The allows the RAM disk on the system to be smaller.