[Patch] Tweak gthr-posix.h for pthread_create() Interceptors

[Ranjit Mathew]

On Fri, 19 Nov 2004 20:03:36 +0530, Ranjit Mathew <rmathew@gmail.com> wrote:
> On Fri, 29 Oct 2004 02:44:44 -0400, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> 
> > On Thu, Oct 28, 2004 at 11:55:11AM -0700, Boehm, Hans wrote:
> >
> > > Ranjit -
> > >
> > > Thanks for pursuing this.  I'd obviously really like to see this fixed.
> > > And I haven't been able to come up with a better solution.
> > >
> > > I'm mildly concerned that pthread_once would have a weakly-defined
> > > stub in glibc which would do the easy thing for a single-threaded
> > > world.  This would allow thread-safe libraries using pthread_once
> > > to run in a single-threaded executable.
> > >
> > > Your testing suggests that this isn't currently the case.  But I
> > > wonder whether it might become true in the future.
> > >
> > > Can some glibc experts comment?  Does it make sense to test
> > > pthread_cond_wait instead, since that probably can't be usefully stubbed
> > > in a single-threaded world, and is much less likely to be intercepted?
> [...]
> > so pthread_cond_wait is not a good test, as for glibc
> > #pragma weak pthread_cond_wait
> > pthread_cond_wait != NULL
> > will be always true, no matter whether libpthread.so has been
> > loaded or not.
> > If you don't like testing for pthread_once, test say pthread_cancel.
> 
> OK, since there were no other suggestions, I went ahead
> with Jakub's suggestion of using pthread_cancel as in the
> attached patch. Tested on i686-pc-linux-gnu with c,c++,java.
> Produced no regressions and fixed the problem.
> 
> OK for mainline?

Since this is a 4.0 regression and this patch fixes it,
can someone please approve it?

Patch here:

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01573.html

The original report+patch here:

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02517.html

Thanks,
Ranjit.