Daniel P. Berrangé <berra...@redhat.com> writes: ... >> Thanks, this fixes it! I had a related question about the way >> qemu_file_monitor_add_watch works. >> >> Am I correct in understanding that if there is already a watch on a dir, >> we return back mon->nextid++ i.e the next free id. Why don't we return >> back the originally assigned watchid ? > > inotify watches are a per-directory scope thing, but this API is aiming > to present the ability to have per-file scope watches as it is more > convenient to have those semantics for some users in QEMU. Thus many > QEMU level watches are mapped to the same low level inotify watch. > > The watch ID is used to unregister a watch later, and while I could have > done ref counting against a common watch ID, I find it clearer to maintain > separate watch IDs for every thing the caller watches. If nothing else it > makes the debugging easier as you can see the relation between events > received and the original watch registration. > Thanks, this makes sense. I think an advantage of having a refcounting mechanism is that we won't run out of watchids because some caller ended up adding a watch on the same dir repeatedly.
> Regards, > Daniel
