On Sun, Mar 04, 2001 at 08:10:14PM -0800, Jeff Bailey wrote: > On Wed, Feb 28, 2001 at 08:09:39PM -0500, Igor Khavkine wrote: > > > Mark Kettenis did substantial work on a native implementation of > > pthreads as part of the glibc. I continued the work and implemented > > most of it, but then I ran out of free time. There are still a > > couple of small but important pieces missing and it has to be properly > > integrated into the glibc build. You can get the latest effort > > from either http://alcor.concordia.ca/~i_khavki/ or > > http://www.fprintf.net/hurd/. > > I took a look at this today. I notice that the build is dependant on > libc right now, so I decided to hack it to be standalone. (build > integration with libc is trivial once it's written) > > It doesn't appear to contain bits/attr.h, which is #include'd by > pthread/pthread.h. I checked the libc sources from CVS and it doesn't > appear there either.
I think this should actually be sysdeps/generic/bits/pt-attr.h. > > The other thing is that bits/pthread.h doesn't have anything that > defines _HURD_THREADVAR_THREAD. I have looked through the various > definiations in the sysdeps directory, but the obvious file > hurd/threadvar.h doesn't contain a definition for this. > This is an enum constant defined in [glibc]/hurd/hurd/threadvar.h, it serves as an index into the stack of a newly created thread. Igor > I haven't gotten past this yet. > > If this thread implementation works for the pieces that have been > written, I would like to package this up as an optional package now. > This means that the current chunks will get tested, and since (IIRC) it > provides functions for all of the cthreads-equivalent functions, it > should be possible to port anything using cthreads to pthreads while we > wait for development to finish. > > -- > My UUism extends beyond national boundaries. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
