Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom scheduling #258

Open
bollian opened this issue Aug 20, 2020 · 0 comments
Open

Custom scheduling #258

bollian opened this issue Aug 20, 2020 · 0 comments

Comments

@bollian
Copy link

bollian commented Aug 20, 2020

I've noticed that notify spawns a thread for each watcher object. This isn't a good fit for the app I'm writing, which really just spends all its time watching a few directories, and terminates on a SIGINT or the like. For this, I really want the code that receives and debounces events to be on the main thread and to simply block on the event source. Would it be possible to allow me to run the notify internal logic in this way?

What would be exceptional, though not strictly necessary, is the ability to integrate this into an async runtime. For example, it's trivially easy to combine the inotify and smol crates to suddenly have an event source sit along side a networked application since inotify allows access to the underlying raw file descriptor. This could be useful if I expand my app in the future.

I guess what I really want this crate to be is a translation layer that turns native fs events into something somewhat consistent across platforms and less so the runtime it is today. I'm even willing to manually call a poll function since I can deal with writing delay logic myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants