gthread API for c++0x thread lib

[Chris Fairles]

On Thu, Aug 7, 2008 at 9:02 AM, Chris Fairles <chris.fairles@gmail.com> wrote:
> I'm currently attempting to update the gthread API to implement
> c++0x's thread library. Attached is a half-baked patch with my current
> progress but besides gthr-posix.h, I'm basically programming blind
> (i.e. no way to test) and so before I go any further I need some
> advice/direction on how to progress from here.
>
> Thus far I've been stuffing extra function prototypes and def'ns
> around the ObjC stuff but there's overlap and I'm not sure how to
> handle it (i.e. duplicated "gthrw" decl's of some pthread funcs).
> Should any additions required by c++0x be guarded by some defined
> macro (kind of like the objc stuff is guarded)?

And now that bootstrap is fixed, ObjC does break due to these dup defs.

>
> As for the arch-specific headers, I can't find any information on the
> MIPS SDE thread API nor am I able to find a list of prototypes in the
> sdethread.h header.
>
> The NKS additions are untested. Not entirely sure how to handle the
> NXContext along with the NXThreadId_t. Currently I grouped them
> together in __gthread_t. Can't really progress much further without
> some run-time testing.
>
> I haven't touched gnat due to lack of info/docs as well (however I
> haven't looked too hard beyond Google). Same deal with rtems. TPF is
> incomplete but it seems to have a one-to-one mapping to pthreads
> anyway so fairly trivial to implement. VXWorks, Solaris and win32 I
> just haven't gotten to yet mainly because I'd be writing code blind
> like NKS etc which certainly isn't very efficient or wise.
>
> Are there emulators available to facilitate testing? I couldn't find a
> testsuite for the gthreads stuff as well, should there be?
>
> In any case, this patch has at least allowed me to start hacking away
> at the c++ thread lib since I'm on a x86_64 posix platform. It doesn't
> break bootstrap the last I checked but
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37045 is currently
> blocking further testing.
>
> Cheers,
> Chris
>