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

[Ulrich . Weigand]

Wolfgang Gloger wrote:
>I agree that the comment is broken, however the MAP_FIXED is more or
>less unavoidable with the current pthread design.

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.

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.

>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 effect is that if you create too many threads, your shared
>> libraries or other mmap()ed areas will simply be overwritten
>> with thread stacks ...
>
>Yes, I noticed that on i586 as well, wenn the address space becomes
>close to full.  I've created a patch to alleviate that problem
>(although admittedly it is no complete solution), which I append
>below.  Basically, if you create a number N of threads early on in the
>program, and don't exceed that number later, everything is fine
>(whereas without the patch, every thread that exits and is created
>again causes one dangerous MAP_FIXED call).

Thanks.  I guess the correct solution for us would be to
upgrade to glibc-2.2 and implement FLOATING_STACKS in our
backend.  Unfortunately, this doesn't appear to be implemented
in glibc-2.1.3 ...


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: address@hidden