[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A common Policy for porting pthread application

Hi ,

 But then I would nice if someone can tell me the the status of the work.
I  found something on  http://fprintf.net/hurd/ . IS there any one
continuing the effort.


Jeff Bailey wrote:

> On Wed, May 16, 2001 at 05:02:07PM +0530, Aneesh Kumar K.V wrote:
> > Hi ,
> >
> >  Is there a common method for porting pthread application? I mean is
> > there a dummy pthread.h file which contain set of macros that will map
> > all sort of pthread functions( atleast mutex functions) to the one
> > available on hurd ?
> cthreads is currently the only threading library that works on the
> hurd.  The reason we can't simply provide easy cthreads->pthreads
> mapping is because pthreads provides so many more functions.
> In general, if your application relies on:
> o mutex locks
> o spin locks
> o thread creation
> o thread_self
> you can port to cthreads without any problems.  However, none of the
> specs that I've read handle any sort of per-thread signal masking, or
> a number of the ideas that pthreads offers.
> I just got (After 3 months of looking) the Oreilly & Ass. pthreads
> programming book.  I'm hoping that it will be a good enough reference
> that I write a simple shim to provide those functions and #error out
> on any calls that aren't easily supported.
> My idea is that with a simple pthreads->cthreads shim, we can then
> port the underlying Hurd servers to pthreads, and not have to worry
> about the complications of running two different threading systems
> (mentioned by Roland a month or so ago).
> Tks,
> Jeff Bailey

Reply to: