Re: [PATCH 09/15] Hurd signals: implement global signal dispositions

[Samuel Thibault <samuel dot thibault at gnu dot org>]

Jeremie Koenig, le Tue 05 Jul 2011 05:15:28 +0200, a écrit :
> > These should probably be made extern inline.
> 
> I agree as far as internal libc usage is concerned.

Yes.  I wasn't meaning extern inline to outside libc. "extern inline"
precisely means that we also provide the symbol, for those who don't
have the definition :)

>   - sigstate_is_global_rcv and sigstate_clear_pending are static
>     functions, which I think gcc will inline if appropriate;

Yes for sigstate_clear_pending, sigstate_is_global_rcv is used in other
"to be inlined?" functions.

>   - _hurd_sigstate_actions is not actually exported by hurd/Versions.
>   - _hurd_sigstate_lock/unlock use _hurd_global_sigstate, which is not
>     exported either.

Not a problem, we can still add an internal extern inline definition.

It doesn't matter much anyway, it's just an optimization.

> > > @@ -210,7 +211,7 @@ set_int (int which, int value)
> > >        /* These are pretty odd things to do.  But you asked for it.  */
> > >      case INIT_SIGMASK:
> > >        {
> > > -	struct hurd_sigstate *ss = _hurd_thread_sigstate (_hurd_sigthread);
> > > +	struct hurd_sigstate *ss = _hurd_global_sigstate;
> > >  	__spin_lock (&ss->lock);
> > >  	ss->blocked = value;
> > >  	__spin_unlock (&ss->lock);
> > 
> > Likewise.
> 
> The only straightforward way to fix this that I can see would be to
> reinstate _hurd_sigthread (maybe as "_hurd_mainthread"), so that we can
> distinguish the main thread from other global signal receivers (in the
> libpthread case).
> 
> Or maybe we could drop this and let them return EINVAL?

I've never seen it used actually. Roland?

> > The SA_ONSTACK logic remains the same.  I believe this is right.  In
> > the Hurd semantic case your patch does not change the behavior.  In the
> > POSIX semantic all threads share the SA_ONSTACK logic.  This is what
> > POSIX says for signals.  I don't think it is a problem for preemptors.
> 
> I was worried about a case where the user would install a minuscule
> stack, sufficient for their own handler, but not for a preemptor's one.

I believe the user is not supposed to know how much the kernel & libc
will need on the stack to handle signals.

Samuel