[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/3] usb-mtp: Add support for inotify based file
From: |
Bandan Das |
Subject: |
Re: [Qemu-devel] [PATCH 2/3] usb-mtp: Add support for inotify based file monitoring |
Date: |
Thu, 12 Nov 2015 17:40:23 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Gerd Hoffmann <address@hidden> writes:
> On Mo, 2015-11-09 at 18:12 -0500, Bandan Das wrote:
>> Gerd Hoffmann <address@hidden> 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
- [Qemu-devel] [PATCH 1/3] usb-mtp: use a list for keeping track of children, (continued)
Re: [Qemu-devel] [PATCH 2/3] usb-mtp: Add support for inotify based file monitoring, Gerd Hoffmann, 2015/11/05
[Qemu-devel] [PATCH 3/3] usb-mtp: add support for basic mtp events, Bandan Das, 2015/11/03