Comments (7)
I'm working with futures-rs (and learning from it) on a personal project. I think implementing futures-rs would be really useful, and should be a target for 0.5. Do you have any thoughts/suggestions (or even existing code) about how to go about this?
from inotify-rs.
I have some thoughts, but not many:
- There's existing code: tokio-inotify, which is a wrapper around an older version of inotify-rs.
- tokio-inotify implements
Stream
. The inotify-rs API has become more low-level since then, so I don't think this will work any longer, as inotify-rs no longer manages a heap-allocated buffer. I'm guessing that returning a future that returns an iterator fromread_events
would be the way to go. - The point where I gave up was when decided what to do about
Handle
. You seem to need aHandle
to do stuff with Tokio. We can probably just assume that a future-enabled API that uses inotify-rs already has aHandle
, but what about end users that don't have one and don't know how to get one? There must be a way to support both use cases conveniently.
That's about it. I still don't have much experience with futures/Tokio. Some of my question might be easy to answer, but I think there will probably be undiscovered problems that I'm not aware of. When I looked into it, I gave up pretty quickly, as it wasn't a high priority at the time (I think it's very important long-term, though).
from inotify-rs.
and should be a target for 0.5
I generally don't like setting such goals for versions, as I prefer to just release when there are enough useful changes. For example, I plan to take a closer look at issue #61 soon. Any improvements in that area, together with your pull request (#67), are already useful enough by themselves. If a futures-based API were ready at the same time, then fine, but if not, it can just go into another release later.
from inotify-rs.
The point where I gave up was when decided what to do about Handle. You seem to need a Handle to do stuff with Tokio. We can probably just assume that a future-enabled API that uses inotify-rs already has a Handle
Yes, the code which creates the event loop holds a Handle
it is used to ensure that the inotify-rs
code runs in the appropriate event loop.
from inotify-rs.
I have a porting based on may, the interfaces are the same as before.
from inotify-rs.
@Xudong-Huang Thanks, but that doesn't help me :) . I'd like to have events available as a Stream
(or equivalent) in future
-speak so that I can mesh it with other event sources, not that it's just backed by asynchronous code.
from inotify-rs.
Thank you for the info, @mathstuf and @Xudong-Huang.
@mathstuf, I currently have no short-term plans to work on this. I'm currently waiting to see how the upcoming futures/tokio changes will shake out. I'm happy to assist with code review and answering questions, if you'd like to take a look at this yourself.
Alternatively, you can take a look at notify. I believe there's ongoing work on the next version, which involves futures. See this issue for more info.
from inotify-rs.
Related Issues (20)
- Consider addressing buffer alignment in a more robust way HOT 2
- `Inotify::event_stream` is error-prone HOT 2
- Add separate API for adding/removing watches
- Implement ToOwned for `Event<&'a OsStr>` HOT 9
- Consider using cargo clippy in test workflows HOT 1
- Consider increasing the buffer size for the stream example HOT 2
- Using Inotify::read_events in async context HOT 3
- Is it possible to get full path from Event? HOT 3
- Update minimum supported Rust version HOT 1
- duplicate event reports HOT 9
- Async runtime agnostic. HOT 2
- Bump MSRV to at least 1.56 HOT 1
- documentation for `Inotify::watches` is broken in 0.10.1 HOT 4
- Invalid argument when trying to monitor /dev/snd HOT 2
- Update dependency `bitflags` to v2? HOT 3
- docs.rs links from inotify to inotify_sys are broken HOT 4
- Fail CI build on doc warnings
- Example in API reference is broken HOT 7
- Recursive Directory Watching HOT 1
- Release with updated dependencies? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from inotify-rs.