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

Using rb-inotify within Async task #43

Closed
brandonhilkert opened this issue Aug 5, 2019 · 5 comments
Closed

Using rb-inotify within Async task #43

brandonhilkert opened this issue Aug 5, 2019 · 5 comments
Assignees

Comments

@brandonhilkert
Copy link

brandonhilkert commented Aug 5, 2019

We're looking to use https://github.com/guard/rb-inotify as a wrapped class that will monitor a path on the filesystem and also invoke other work. We're seeing the monitor get blocked on startup of the Reactor.

Here's a simplified example

Async::Reactor.run do |task|
  task.async do |subtask|
    SyslogMonitor.run
  end

  task.async do |subtask|
    while true
      periodic_work
      subtask.sleep 300
    end
  end
end

class SyslogMonitor
  def self.run
    Async do |task|
      File.open(LOG_PATH, "r") do |f|
        f.seek(0, IO::SEEK_END)

        queue = INotify::Notifier.new

        queue.watch(LOG_PATH, :modify) do
          change = f.read

          Async do |task|
            task.sleep 2
            process_change
          end
        end

        queue.run
      end
    end
  end
end

Would we have to use rb-inotify differently for it to be compatible with the reactor?

BTW - the whole family of async gems have been incredibly helpful. Thanks so much for your time and effort on them!

@ioquatix
Copy link
Member

ioquatix commented Aug 5, 2019

@brandonhilkert I'm happy to hear it's been super useful - if you have commercial use case please consider sponsoring a gem within the eco-system: https://github.com/socketry/community#funding

Does rb-inotify expose a file descriptor? If so, you need to put it into an Async::Wrapper and wait on it. Otherwise, it will block the task.

The other option is to use a thread to run the queue.watch and feed events back using a queue. However, that is more work and less efficient.

So, my first suggestion is to check how we can integrate it better.

@brandonhilkert
Copy link
Author

I assume your comment here would be the idea, right?

@ioquatix
Copy link
Member

ioquatix commented Aug 5, 2019

Yes, that's basically it.

wrapper = Async::Wrapper.new(io)
wrapper.wait_readable

io.read

@ioquatix
Copy link
Member

ioquatix commented Jul 5, 2020

Feel free to give me an update. We should add documentation to clarify this use case.

@ioquatix ioquatix self-assigned this Jul 5, 2020
@ioquatix
Copy link
Member

ioquatix commented Nov 1, 2022

In Async 2.x world, all IO is now non-blocking, so this should be a non-issue. Please try it out and open a new issue if you are still having problems.

@ioquatix ioquatix closed this as completed Nov 1, 2022
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