qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Bandan Das <bsd@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/3] usb-mtp: Add support for inotify based file monitoring
Date: Thu, 12 Nov 2015 09:16:21 +0100	[thread overview]
Message-ID: <1447316181.1400.21.camel@redhat.com> (raw)
In-Reply-To: <jpgtwoupy1e.fsf@linux.bootlegged.copy>

On Mo, 2015-11-09 at 18:12 -0500, Bandan Das wrote:
> Gerd Hoffmann <kraxel@redhat.com> 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

  parent reply	other threads:[~2015-11-12  8:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-04  0:00 [Qemu-devel] [PATCH 0/3] usb-mtp events support Bandan Das
2015-11-04  0:00 ` [Qemu-devel] [PATCH 1/3] usb-mtp: use a list for keeping track of children Bandan Das
2015-11-05  8:24   ` Gerd Hoffmann
2015-11-05 21:23     ` Bandan Das
2015-11-04  0:00 ` [Qemu-devel] [PATCH 2/3] usb-mtp: Add support for inotify based file monitoring Bandan Das
2015-11-05  8:37   ` Gerd Hoffmann
2015-11-05 21:28     ` Bandan Das
2015-11-05  8:49   ` Gerd Hoffmann
2015-11-09 23:12     ` Bandan Das
2015-11-09 23:28       ` Bandan Das
2015-11-12  8:16       ` Gerd Hoffmann [this message]
2015-11-12 22:40         ` Bandan Das
2015-11-13  8:08           ` Gerd Hoffmann
2015-11-05  8:49   ` Gerd Hoffmann
2015-11-09 23:13     ` Bandan Das
2015-11-04  0:00 ` [Qemu-devel] [PATCH 3/3] usb-mtp: add support for basic mtp events Bandan Das
2015-11-05  8:41   ` Gerd Hoffmann
2015-11-05 21:30     ` Bandan Das

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1447316181.1400.21.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=bsd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).