bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mmap(...MAP_FIXED...) in pthread_allocate_stack ???


From: Wolfram Gloger
Subject: Re: mmap(...MAP_FIXED...) in pthread_allocate_stack ???
Date: Mon, 11 Dec 2000 18:08:03 +0100 ("MET)

Hello,

> Hmmm.  At least on Linux, if you omit the MAP_FIXED, the kernel
> will try to use the specified address anyway;  only if this is
> not available it will choose another address.  So on Linux, you
> could just call mmap(), check whether it returned the correct
> address, and if not, fail safely.

Very nice, I didn't realize that.  I just checked on Linux 2.0 and
2.2, that this really is the case.

> On the other hand, this doesn't work on other OSes; on Solaris
> e.g. the address is never honored unless you specify MAP_FIXED.

Yes, I was aware of that.  However, I think we should be able to
assume that LinuxThreads runs mainly on Linux :-).

I think I'm going to submit a patch for manager.c that does away with
MAP_FIXED on Linux.

> >Exception: if there
> >is a register available to hold the thread_self pointer, then
> >FLOATING_STACKS can be defined in this file and MAP_FIXED isn't used.
> >Check out i686/useldt.h for an example.
> 
> Well, we could do this on S/390.  B.t.w. why is useldt only used
> on i686?  It should work on any Intel processor, no?

The perceived problem was that ldt switching could be very slow on
some older processors.  This hasn't yet been completely investigated.

> Thanks.  I guess the correct solution for us would be to
> upgrade to glibc-2.2 and implement FLOATING_STACKS in our
> backend.

Yes, definitely.

Regards,
Wolfram.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]