The deletion events are not provided in time about libinotify-kqueue HOT 16 CLOSED

Can this be related to #11?

from libinotify-kqueue.

Probably, I'm now working on this.

from libinotify-kqueue.

Please tell if we can help with testing. We will have time for that in Monday.

from libinotify-kqueue.

Ok, thanks!

from libinotify-kqueue.

Still observing some issues.

from libinotify-kqueue.

Yepp. Looks like there is a misuse of EV_ONESHOT, with this flag NOT set, the changes in directory are being detected correctly, but other issues appear. Will investigate/fix it later.

from libinotify-kqueue.

Yep, it is really there. Will rework the event processing routines soon.

from libinotify-kqueue.

No need to rework. It has been done already by myself about a year ago. Now I settled resulting code on my GH page. Take a look on it
On topic: Using EV_ONESHOT instead of EV_CLEAR led this project to make 2 bad things:

1. create brain-damaged structure called worker-sets.
2. Lose events firing while other event is being processed by library. Most often lose NOTE_WRITE on a watched directory

from libinotify-kqueue.

Wow, cool. Why you did not send any comments/pull requests for that?

from libinotify-kqueue.

As many other GSOC projects this one looks like "wrote and forgot" one that time. And my code was not in good shape to be published. But since I had to resolve conflicts on update of port system in devel/libinotify directory I decided to blow the dust off my old work and spend some time to make it ready for publishing

from libinotify-kqueue.

This project LOOKED like "wrote and forgot" not LOOKS. My bad. Sorry

from libinotify-kqueue.

Actually, I was in army in 2012-2013, so really there were no commits. Though the people who were really interested in the project contacted me by e-mail and I'd collected some feedback. I have planned to do benchmarking and refactoring work, but now I have time only for bugfixing (still, it takes weeks to get a single issue resolved). The ONESHOT<-->CLEAR is a really idiotic one, I agree.

I've took a brief look on the list of your changes (just commit messages, no code review), and it looks pretty interesting. It seems you've implemented the things I've been thinking about from time to time.

I am fine with integrating your changes into the main branch, if it does not break the portability. What is about making a series of pull-requests so I could review the actual changes sequentially? I see that your code is rebased with my recent changes, so there should not be many problems.

from libinotify-kqueue.

Ok. I'll try to rearrange my commits to be a logical independent series of changes. But it's a long term task due to one reason: There were transition from monolithic array called worker-sets with its 1:1:1 relation between kqueue changes, kqueue (sub)watches and (sub)files to a linked list of inotify watches with its m:n indirect (via inode number) relation between watches and files. So moving a source code through this (fuzzy) fence leads to its (code) rewrite :-(

from libinotify-kqueue.

I hope to publish first part of changes within a week

from libinotify-kqueue.

Closing as no longer applicable as @wulf7 stole the show. :)

from libinotify-kqueue.

For the curious minds: https://github.com/libinotify-kqueue/libinotify-kqueue

from libinotify-kqueue.