Re: _lwp_create change

[christos%astron.com@localhost (Christos Zoulas)]

In article <oda7lg$bud$1%blaine.gmane.org@localhost>,
Christos Zoulas <christos%astron.com@localhost> wrote:
>In article <20170420113134.GB23195%britannica.bec.de@localhost>,
>Joerg Sonnenberger  <joerg%bec.de@localhost> wrote:
>>On Thu, Apr 20, 2017 at 06:48:01AM +0200, Martin Husemann wrote:
>>> On Thu, Apr 20, 2017 at 02:29:26AM +0200, Joerg Sonnenberger wrote:
>>> > As discussed previously, I think the patch makes the behavior worse and
>>> > the Go implementation is kind of stupid as well.
>>> 
>>> No comment on the patch of the go implementation, but I think that the
>>> code should actually do what the documentation says:
>>> 
>>> 	The context argument specifies the
>>>      initial execution context for the new LWP including signal mask, stack,
>>>      and machine registers.
>>> 
>>> Specifying the signal stack in the create call does make sense to me.
>>
>>Note: stack here means the regular stack. It is not "signal mask, signal
>>stack, stack, machine registers". Christos wants to overload the stack
>>field to be polymorphic. I don't mind fixing the signal mask handling,
>>that's a clear bug. Changing the stack to have a new double meaning is
>>bad though.
>
>It always has a double meaning... Check out the source in getucontext:

Can we come to some consensus of what we should do here:

- 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.

- 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.

christos