Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 6 Oct 2020 18:35:34 -0700
From:   dmitry.torokhov@gmail.com
To:     kl@kl.wtf
Cc:     linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Input: evdev - per-client waitgroups
Message-ID: <20201007013534.GT1009802@dtor-ws>
References: <20201005233500.GM1009802@dtor-ws>
 <20200429184126.2155-1-kl@kl.wtf>
 <0ec848359962ebce267168618b816bb4@kl.wtf>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0ec848359962ebce267168618b816bb4@kl.wtf>
Precedence: bulk

On Tue, Oct 06, 2020 at 09:15:32AM +0000, kl@kl.wtf wrote:
> October 6, 2020 1:35 AM, dmitry.torokhov@gmail.com wrote:
> 
> > On Wed, Apr 29, 2020 at 08:41:26PM +0200, Kenny Levinsen wrote:
> > 
> >> All evdev clients share a common waitgroup. On new input events, this
> >> waitgroup is woken once for every client that did not filter the events,
> > 
> > I am having trouble parsing the changelog (I think I agree with the
> > change itself). Did you mean to say "this waitqueue wakes up every
> > client, even ones that requested to filter out events that are being
> > delivered, leading to duplicated and unwanted wakeups"?
> 
> Ah, I suppose my original wording was a bit convoluted. Perhaps the following
> is clearer:
> 
> 	All evdev clients share a common waitgroup. On new input events, all
> 	clients waiting on this waitgroup are woken up, even those filtering
> 	out the events, possibly more than once per event. This leads to
> 	duplicated and unwanted wakeups.
> 
> What I tried to say is that not only do all clients polling the device/blocked
> on read end up woken up, instead of being woken just once, they are woken once
> for every client that was interested in the event.
> 
> So, if you have two clients interested and one uninterested, then the shared
> waitgroup that all three clients are waiting on is woken up twice in a row.
> 
> Should I send an updated patch with the new wording? I'm also fine with your
> suggested wording if you prefer that.

I used the new description from above and applied, thank you.

-- 
Dmitry