On 08/28, Roland McGrath wrote:
>
> > I seem to understand what you mean... Yes, at first glance, we can consider
> > the sub-thread with ->exit_state != 0 as "dead enough" for de_thread. This
> > allows us to simplify the logic greatly.
>
> I can't really think of any definite problem with that o
> I seem to understand what you mean... Yes, at first glance, we can consider
> the sub-thread with ->exit_state != 0 as "dead enough" for de_thread. This
> allows us to simplify the logic greatly.
I can't really think of any definite problem with that off hand. Aside
from stray BUG_ON's, that is
On 08/19, Roland McGrath wrote:
>
> I had in mind unifying this need with what's now done by the notify_count
> check that's in __exit_signal. Aside from those BUG_ON's, I'm not sure
> de_thread really cares whether the other non-leader threads are finished
> self reaping, or only if they are dead
> ? This becomes a busy-wait loop if the leader sleeps, wait_task_inactive()
> doesn't sleep/yield in this case. Not good.
Ah, I see. Yes, you're right, that will not fly. (I was thinking of the
apparently forthcoming wait_task_inactive change to avoid yield, but that
will still busy-wait in fac
On 08/19, Roland McGrath wrote:
>
> > The group_leader can sleep before it enters exit_notify(). In that case
> > wait_task_inactive() returns, and we still need some polling to wait for
> > EXIT_ZOMBIE.
>
> It could be a loop as now with yield. It's still polling, but only one
> poll per wakeup
> The group_leader can sleep before it enters exit_notify(). In that case
> wait_task_inactive() returns, and we still need some polling to wait for
> EXIT_ZOMBIE.
It could be a loop as now with yield. It's still polling, but only one
poll per wakeup of the target.
> Yes sure. But in any case I
On 08/18, Roland McGrath wrote:
>
> Maybe it can use wait_task_inactive, which IIUC is being changed to address
> the same RT issue.
The group_leader can sleep before it enters exit_notify(). In that case
wait_task_inactive() returns, and we still need some polling to wait for
EXIT_ZOMBIE.
> OTOH
Maybe it can use wait_task_inactive, which IIUC is being changed to address
the same RT issue. OTOH, notify_count exists only for this. So maybe the
better way is to clean that whole mechanism up somehow. The exit.c changes
in your patch seem to be making it more mysterious rather than less so.
de_thread() yields waiting for ->group_leader to be a zombie. This deadlocks
if an rt-prio execer shares the same cpu with ->group_leader. Change the code
to use ->group_exit_task/notify_count mechanics.
This patch certainly uglifies the code, perhaps someone can suggest something
better.
Signed-
9 matches
Mail list logo
