From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwn3X-0003xd-4V for qemu-devel@nongnu.org; Thu, 12 Nov 2015 03:16:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwn3S-0005ur-4a for qemu-devel@nongnu.org; Thu, 12 Nov 2015 03:16:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwn3R-0005u5-UF for qemu-devel@nongnu.org; Thu, 12 Nov 2015 03:16:26 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id D90C98F515 for ; Thu, 12 Nov 2015 08:16:24 +0000 (UTC) Message-ID: <1447316181.1400.21.camel@redhat.com> From: Gerd Hoffmann Date: Thu, 12 Nov 2015 09:16:21 +0100 In-Reply-To: References: <1446595225-23608-1-git-send-email-bsd@redhat.com> <1446595225-23608-3-git-send-email-bsd@redhat.com> <1446713343.30393.16.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/3] usb-mtp: Add support for inotify based file monitoring List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bandan Das Cc: qemu-devel@nongnu.org On Mo, 2015-11-09 at 18:12 -0500, Bandan Das wrote: > Gerd Hoffmann writes: > > > On Di, 2015-11-03 at 19:00 -0500, Bandan Das wrote: > >> + /* Add a new watch asap so as to not lose events > >> */ > > > > This comment sounds like there is a race ("asap"). There isn't one, > > correct ordering (adding the watch before reading the directory) is > > Hmm, seems like there's still a small window. We may not have even > started processing the event because we are still processing the earlier > ones. > > enough to make sure you don't miss anything. You might see create > > events for objects already in the tree though, are you prepared to > > handle that? > > Oh, interesting. Current version will happily add duplicate entries. > I will add a check. I think we are talking about the same thing here. Things can run in parallel, like this: process copying a file tree | qemu with usb-mtp ----------------------------+-------------------------- create directory | | inotify event #1 queued (dir) | qemu fetches event #1 | qemu adds new inotify watch copy file into new dir | | inotify event #2 queued (file) | qemu reads new directory | qemu finds the new file | qemu fetches event #2 So, yes, the kernel can add new inotify events for the new watch before qemu finished processing the old event (especially before you are done reading the directory), and if you are hitting that the effect is that you see a create event for the new file even though you already have it in the tree. But it is impossible that you miss the creation of the new file (this is what I meant with "there is no race"). hope this clarifies, Gerd