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

abnormal termination fails silently + burns cpu #81

Merged
merged 4 commits into from
Mar 3, 2018
Merged

abnormal termination fails silently + burns cpu #81

merged 4 commits into from
Mar 3, 2018

Conversation

saluzafa
Copy link
Contributor

fix: use @pipe.read_nonblock(1) instead of @pipe.read(1)
fix: rescue EOFError (raised by #read_nonblock) and wait 1 seconds before iterating over

fix: use @pipe.read_nonblock(1) instead of @pipe.read(1)
fix: rescue EOFError (raised by #read_nonblock) and wait 1 seconds before iterating over
@thibaudgg
Copy link
Member

Hi @saluzafa, thanks for your pull request, this is much appreciated.

Could you please add some more details are both fixes explaining why they needed and which issue they are particularly addressing.

If not too complicated, adding specs would be also great.

@sbleon
Copy link
Member

sbleon commented Mar 2, 2018

+1 for merging this change. It prevents 100+ CPU utilization by fsevent_watch when I start my Rails 5 project with bin/rails s. I'll be using @saluzafa's fork for now.

@thibaudgg
Copy link
Member

@sbleon that's great to hear, I'm also looking merging that PR!
I would just like to see a bit more context in the commit message.

@saluzafa
Copy link
Contributor Author

saluzafa commented Mar 3, 2018

Hello there!
When a process running fsevent_watch is abnormally terminated, @pipe.read(1) hangs and try to read data from a pipe that is actually closed. To prevent this behaviour, I tought of using a non-block read. When #read_nonblock can't read anything it raises an EOFError exception, so I'm catching this exception and the process terminates properly.

I'm going to remove the useless part rescue EOFError [...] since EOFError is a child of IOError (handled at line 82).

Have a good week-end :)

@thibaudgg
Copy link
Member

@saluzafa great, thanks for the explanation!

@thibaudgg thibaudgg merged commit c08d62c into guard:master Mar 3, 2018
@saluzafa
Copy link
Contributor Author

saluzafa commented Mar 3, 2018

Welcome :), I just noticed that I forgot to bump the version number, are you going to do it by yourself later or do you want me to do it now? Cheers!

@thibaudgg
Copy link
Member

I just did it, version 0.10.3 is out!

@sbleon
Copy link
Member

sbleon commented Mar 5, 2018 via email

@padi
Copy link

padi commented Apr 20, 2018

I've held on commenting until I've made installed 10.3 and observed for a few weeks.

When I use spring (which this gem uses) in a Rails 5.1 project, I still get 100% cpu usage some of the time.

Not sure how I can falsify other than occassionally seeing 100% cpu in ruby. Do I need to update to the latest macOS? I'm currently in macos 10.12.6

Thanks so much for possibly resolving this long-time issue!

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

Successfully merging this pull request may close these issues.

None yet

4 participants