From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zx0Xa-0007cH-Jv for qemu-devel@nongnu.org; Thu, 12 Nov 2015 17:40:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zx0XZ-00046M-Ip for qemu-devel@nongnu.org; Thu, 12 Nov 2015 17:40:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zx0XZ-00046F-DC for qemu-devel@nongnu.org; Thu, 12 Nov 2015 17:40:25 -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 1F483C1A0BD0 for ; Thu, 12 Nov 2015 22:40:25 +0000 (UTC) From: Bandan Das 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> <1447316181.1400.21.camel@redhat.com> Date: Thu, 12 Nov 2015 17:40:23 -0500 In-Reply-To: <1447316181.1400.21.camel@redhat.com> (Gerd Hoffmann's message of "Thu, 12 Nov 2015 09:16:21 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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: Gerd Hoffmann Cc: qemu-devel@nongnu.org Gerd Hoffmann writes: > 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 Maybe I am missing something but what if the watch on dir was added by qemu _after_ the file (say file1) was copied to it. Then, the kernel would generate events for file2, file3 and so on but never a CREATE event for file1. Isn't that a possibility ? So, what I mean by that comment is that add a watchpoint soon enough but it could be possible that by the time the watch is added, a few files might have already been copied and will not generate events. > 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