Mail Archives: cygwin/2001/04/10/14:55:30
----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Tuesday, April 10, 2001 12:39 AM
Subject: Re: G++ guru's please comment - Re: FW: pthread_create problem
in Cygwin 1.1.8-2]
> On Mon, Apr 09, 2001 at 10:09:54PM +1000, Robert Collins wrote:
> >> The error you get is a result of a race condition on a lookup table
> >> shared by all threads. The stack is NOT corrupted in any way.
> >
> >It's not a race condition per se (timing has nothing to do with it,
it's
> >guaranteed if two or more threads enter a try block concurrently).
> >Something in g++ is dsiabled when it's built without thread support,
and
> >it returns the same base address for the context struct for each
thread.
> >That function should return a different context regardless IMO,
unless
> >they are using pthread_key_create, which I have also implemented.
There
> >is a patch for that in the cygwin patch list archives, and hopefully
> >it'll be in CVS soon.
>
> Isn't this patch gated on newlib changes? If not, I missed it. I
thought
> we were still waiting on final word on newlib reorganization.
I mailed cygwin-patches late last night. The final word is
a) Don't alter RTEMS types yet.
b) Do what I started to do and split the types into separate files. If
we have time to do RTEMS great.
c) cygwin should look at using the newlib pthread.h include (which we
don't currently).
As my patch is a step in the right direction, I see no issue with it
going in, and later work completing the rearrangement.
Rob
>
> cgf
>
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -