Pthreads.

Pthreads.

[J. Scott Kasten]

If I recall correctly, some time ago, Jun Sun was looking at pthreads.
What is the status of threads in glibc-2.0.6/.7 and glibc-2.2.x for mips?
I.E. works, broken, how bad, to do???

Thanks.

--

J. Scott Kasten
Email: jsk AT tetracon-eng DOT net

"Nearly all men can stand adversity,
 but if you want to test a man's
 charater, give him power. - A Lincoln"

Pthreads.

[J. Scott Kasten]

If I recall correctly, some time ago, Jun Sun was looking at pthreads.
What is the status of threads in glibc-2.0.6/.7 and glibc-2.2.x for mips?
I.E. works, broken, how bad, to do???

Thanks.

--

J. Scott Kasten
Email: jsk AT tetracon-eng DOT net

"Nearly all men can stand adversity,
 but if you want to test a man's
 charater, give him power. - A Lincoln"

Re: Pthreads.

[Jun Sun]

"J. Scott Kasten" wrote:
> 
> If I recall correctly, some time ago, Jun Sun was looking at pthreads.
> What is the status of threads in glibc-2.0.6/.7 and glibc-2.2.x for mips?
> I.E. works, broken, how bad, to do???
> 

I found a bug in the kernel that causes register corruption, which causes
pthread to fail.  The bug has been fixed for a while in the CVS tree.  I don't
recall any glibc specific patches.  

Yes, it runs fine on my machines.

Jun

Re: Pthreads.

[J. Scott Kasten]

On Wed, 30 May 2001, Jun Sun wrote:

> "J. Scott Kasten" wrote:
> >
> > If I recall correctly, some time ago, Jun Sun was looking at pthreads.
> > What is the status of threads in glibc-2.0.6/.7 and glibc-2.2.x for mips?
> > I.E. works, broken, how bad, to do???
> >
>
> I found a bug in the kernel that causes register corruption, which causes
> pthread to fail.  The bug has been fixed for a while in the CVS tree.  I don't
> recall any glibc specific patches.

If I recall correctly, that was S0 not being preserved under certain
system calls.  Which I have taken care of.

>
> Yes, it runs fine on my machines.
>
> Jun
>

When you say runs fine, do you mean the 2.0.x, the 2.2.x or both?

Thanks for your response.

Re: Pthreads.

[J. Scott Kasten]

On Wed, 30 May 2001, Jun Sun wrote:

> "J. Scott Kasten" wrote:
> >
> > If I recall correctly, some time ago, Jun Sun was looking at pthreads.
> > What is the status of threads in glibc-2.0.6/.7 and glibc-2.2.x for mips?
> > I.E. works, broken, how bad, to do???
> >
>
> I found a bug in the kernel that causes register corruption, which causes
> pthread to fail.  The bug has been fixed for a while in the CVS tree.  I don't
> recall any glibc specific patches.

If I recall correctly, that was S0 not being preserved under certain
system calls.  Which I have taken care of.

>
> Yes, it runs fine on my machines.
>
> Jun
>

When you say runs fine, do you mean the 2.0.x, the 2.2.x or both?

Thanks for your response.

Re: Pthreads.

[Jun Sun]

"J. Scott Kasten" wrote:
> 
> On Wed, 30 May 2001, Jun Sun wrote:
> 
> > "J. Scott Kasten" wrote:
> > >
> > > If I recall correctly, some time ago, Jun Sun was looking at pthreads.
> > > What is the status of threads in glibc-2.0.6/.7 and glibc-2.2.x for mips?
> > > I.E. works, broken, how bad, to do???
> > >
> >
> > I found a bug in the kernel that causes register corruption, which causes
> > pthread to fail.  The bug has been fixed for a while in the CVS tree.  I don't
> > recall any glibc specific patches.
> 
> If I recall correctly, that was S0 not being preserved under certain
> system calls.  Which I have taken care of.
> 
> >
> > Yes, it runs fine on my machines.
> >
> > Jun
> >
> 
> When you say runs fine, do you mean the 2.0.x, the 2.2.x or both?
> 
> Thanks for your response.

Both.  There are some bug fixes needed to the get the new glibc 2.2.x
working.  Once the fixes are settled, we will post them.

Jun

Pthreads

[ralf]

Hi all,

for all those who don't get the CVS commit logs - I've fixed the problem
in the libc wrapper for the clone system call; kernel threads seem now
to be running almot perfect.

The only nit which I still observe is that for newly created threads the
stacks will be allocated from KSEG0 on downward.  When creating many
threads somewhen the address space for the stacks will collide with the
address space where libraries etc. are mmap(2)ed, resulting in a SIGSEGV.

This never seems to happen on Intel because there we have one 1gb more
of address space, so the process table will usually be filled (by default
1024 entries) before this collission happens.  Looks like a buglet in
pthreads which doesn't seem to be very critical for now, but which wants
to be researched.

There are some more libc things to be done and I'll provide an updated
libc asap.

  Ralf