This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] Tweak gthr-posix.h for pthread_create() Interceptors
- From: Ranjit Mathew <rmathew at gmail dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: "Boehm, Hans" <hans dot boehm at hp dot com>
- Date: Fri, 3 Dec 2004 10:52:41 +0530
- Subject: Re: [Patch] Tweak gthr-posix.h for pthread_create() Interceptors
- References: <94505C6A90226146BD46E87646B4402F4A9106@cacexc11.americas.cpqcorp.net> <20041029064444.GR12650@devserv.devel.redhat.com> <email@example.com>
- Reply-to: Ranjit Mathew <rmathew at gmail dot com>
On Fri, 19 Nov 2004 20:03:36 +0530, Ranjit Mathew <firstname.lastname@example.org> wrote:
> On Fri, 29 Oct 2004 02:44:44 -0400, Jakub Jelinek <email@example.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?
The original report+patch here: