This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Fri, 29 Oct 2004 02:44:44 -0400, Jakub Jelinek <> 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 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?


Ranjit Mathew          Email: rmathew AT gmail DOT com

Bangalore, INDIA.      Web:

Attachment: gthr.txt
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]