Re: _lwp_create change

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Thu, Apr 20, 2017 at 03:45:23PM +0000, Christos Zoulas wrote:
> - It is agreed that we'll fix at least the signal mask propagation from
>   the supplied user context to the new thread as documented in the man
>   page.

Fine with me.

> - Currently _lwp_makecontext sets uc_stack (in a bogus way) but this is
>   uc_stack setting is not used; the choices are:
> 
> 	1. Leave it as it is and document that the signal stack is not
> 	   used from the context in _lwp_create. Also document that
> 	   the signal stack is copied from the parent thread so
> 	   using sigaltstack with _lwp_create will not work without
> 	   the user being responsible for setting the stack manually
> 	   on newly created threads.
> 	2. Fix the kernel to treat the stack supplied by the context
> 	   as the stack to be used (in my proposed patch). Optionally
> 	   later fix _lwp_makecontext() to either:
> 		- allocate a signal stack for the new thread if SS_DISABLED
> 		  is not set in the current thread, or 
> 		- do what others do (set SS_DISABLED for the new thread).
> 	   document the behavior.
> 	3. Fix the kernel to just set SS_DISABLED for new threads since
> 	   inheriting the signal stack from the current thread will never
> 	   work (what others do). Document that in _lwp_create. Optionally
> 	   remove the uc_stack setting code in _lwp_makecontext.

(1) >> (2) >> (3)

As I said, I consider (3) a functional regression. I don't like the
semantic overload of (2), especially since it makes the interface even
less orthogonal. All ucontext using interface must die and be replaced
with something sane, so making them more complicated doesn't help.

Joerg