This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: pthread_exit behavior from main
On Thu, Oct 4, 2012 at 9:53 PM, Godmar Back <godmar@gmail.com> wrote:
> On Thu, Oct 4, 2012 at 9:51 PM, Carlos O'Donell <carlos@systemhalted.org> wrote:
>> On Thu, Oct 4, 2012 at 9:41 PM, Godmar Back <godmar@gmail.com> wrote:
>>> On Thu, Oct 4, 2012 at 9:09 PM, Carlos O'Donell <carlos@systemhalted.org> wrote:
>>>>
>>>> You are seeing the undefined results of reading memory that the
>>>> runtime has marked with madvise as MADV_DONTNEED.
>>>>
>>>
>>> Just out of curiosity, why do you madvise it with MADV_DONTNEED rather
>>> than munmapping it outright?
>>
>> That's a very good question and I don't have a good answer.
>
> I'm going to guess that perhaps calling munmap on your current stack
> would pull the exiting thread's rug under its feets, so might have to
> be coded in assembly language to ensure there are no stack accesses
> between the unmap call and the pthread_exit() call.
No, I don't see that as a problem.
You free the stack *after* pthread_exit() has returned from
handling the cancellation.
You should be able to issue munmap to free back 95%
of the stack, leaving only a small part for compliance with
PTHREAD_MIN_STACK, TLS, and the thread descriptor.
Handling signals at this point gets tricky.
Cheers,
Carlos.