> You are not wrong, but I'd rather leave the comment as is, as it will
> vary from user to user. The comments in the sched wake_q bits are
> already pretty clear, and if users cannot see the need for holding
> reference and the task disappearing on their own they have no business
> using wake_q. F
On Fri, 2015-05-01 at 17:52 -0400, George Spelvin wrote:
> In general, Acked-by, but you're making me fix all your comments. :-)
>
> This is a nice use of the wake queue, since the code was already handling
> the same problem in a similar way with STATE_PENDING.
>
> > * The receiver accepts the
In general, Acked-by, but you're making me fix all your comments. :-)
This is a nice use of the wake queue, since the code was already handling
the same problem in a similar way with STATE_PENDING.
> * The receiver accepts the message and returns without grabbing the queue
>+ * spinlock. The use
This patch moves the wakeup_process() invocation so it is not done under
the info->lock by making use of a lockless wake_q. With this change, the
waiter is woken up once it is STATE_READY and it does not need to loop
on SMP if it is still in STATE_PENDING. In the timeout case we still need
to grab
4 matches
Mail list logo
