On Tue, Nov 20, 2018 at 08:19:22PM -0800, Philip Guenther wrote: > On Tue, 20 Nov 2018, Josh Elsasser wrote: > > The test suite for lang/sbcl has uncovered a race between pthread_join() > > and the exiting thread: it may return before it's safe to unmap a custom > > thread stack. > > > > In the exiting thread: > > 1) pthread_exit() calls _thread_release() via the tc_thread_release > > pointer. > > 2) _thread_release() eventually calls _sem_post(&thread->donesem), > > and then returns. > > 3) pthread_exit() then calls __threxit(&tib->tib_tid). > > > > In the joining thread, _sem_wait(&thread->donesem, ...) then returns, > > possibly before the exiting thread has reached __threxit(). > > and that's *perfectly* legal by the spec. The stack is relying on > behavior above and beyond the POSIX spec. To quote XBD 2.9.8, "Use of > Application-Managed Thread Stacks": > The application grants to the implementation permanent ownership of and > control over the application-managed stack when the attributes object in > which the stack or stackaddr attribute has been set is used, either by > presenting that attribute's object as the attr argument in a call to > pthread_create() that completes successfully, or by storing a pointer to > the attributes object in the sigev_notify_attributes member of a struct > sigevent and passing that struct sigevent to a function accepting such > argument that completes successfully. The application may thereafter > utilize the memory within the stack only within the normal context of > stack usage within or properly synchronized with a thread that has been > scheduled by the implementation with stack pointer value(s) that are > within the range of that stack. In particular, the region of memory > cannot be freed, nor can it be later specified as the stack for another > thread. > > Per that last sentence, the SBCL test program is invalid.
Thanks for the clarification. I passed it upstream and sbcl will now start threads with the os-allocated stack and then trampoline to the custom stack.
