Hi,
On Mon, 30 Apr 2018 12:41:47 +0200
"Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> wrote:
[...]
> >> 2. Possibly, I am misreading the code, but the SIGXCPU signal
> >> appears to be a process-directed signal, rather than a
> >> thread-directed signal? Am I correct, and if so, is that really
> >> the desired behavior?
> >>
> >
> > Actually, I can't remember and need to check the code.
>
> So, I went back and reviewed the kernel course. Indeed the signal
> seems to be process-directed:
>
> static inline void check_dl_overrun(struct task_struct *tsk)
> {
> if (tsk->dl.dl_overrun) {
> tsk->dl.dl_overrun = 0;
> __group_send_sig_info(SIGXCPU, SEND_SIG_PRIV, tsk);
> }
> }
>
> __group_send_sig_info() sends a signal to a thread group.
>
> This smells buggy. In sched_setattr(), we are setting per-thread
> scheduling attributes. Surely, the signal should be thread-directed
> when an overrun occurs? Otherwise, how does the application know
> which thread overran?
Sorry for jumping late in the discussion...
Anyway, I agree that there is a bug here (thanks for noticing!), and
the signal was originally designed (in my understanding) to be
thread-directed.
However, I recently participated to a discussion (at OSPM) in which it
was suggested that a process-directed signal can sometimes be more
useful (SIGXCPU is sent when the thread is throttled, so it cannot be
handled until the start of a new period... Having a "manager thread"
that receives the SIGXCPU signals for the process can help in reacting
more quickly).
Of course, this would require some changes, to somehow add to the
signal some information about the throttled thread.
Thanks,
Luca
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
