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
