Abstracting the threads package a little better

[Corey Minyard]

Wolfram Gloger <wg@malloc.de> writes:

> Hello,
> 
> > 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).
> 
> Hmm, you have noticed malloc/thread-m.h, right?  I don't immediately
> understand how you want to abstract `better' than that.

I actually used that model for everything.  The main problem was the
mutex initializers and the size taken by a mutex.  I tried to divorce
the libc stuff from the "pthread.h" include file.  The mutexes I had
were larger than the pthread_mutex_t ones, so I couldn't just use the
same space, I had to reserve some extra space.  And I had to make sure
all the mutexes were initialized properly, for which I cheated and
used a function put into the .ctors section to initialize.

> 
> > 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.
> 
> For malloc, the static initializers aren't necessary, you could define
> MUTEX_INITIALIZER in your version/part of thread-m.h as you wish, as
> long as mutex_init() does the right thing.
> 
> > 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:
> >      http://home.members.net/minyard
> 
> I can't get there right now due to a DNS error.

That's because I messed up the address.  Try http://members.home.net/minyard .
Sorry about that.  If I was dyslexic, I could blame it on that, but I have
no excuse :-).

Thanks,

-Corey