This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Abstracting the threads package a little better

Hello all,

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
employer ready.


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
     this patch.

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]