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

watcher.Close() is hanging forever on OSX #89

Closed
ryanwalls opened this issue Aug 26, 2015 · 5 comments · Fixed by #480
Closed

watcher.Close() is hanging forever on OSX #89

ryanwalls opened this issue Aug 26, 2015 · 5 comments · Fixed by #480
Assignees
Labels

Comments

@ryanwalls
Copy link

I'm using the standard pattern presented in the samples file. Running the watcher from within a unit test and the unit test never exits when watcher.Close() is called.

Let me know what details would be useful.

@nathany
Copy link
Contributor

nathany commented Aug 29, 2015

If you can share some sample code to reproduce the issue, that would be helpful..

@nathany nathany added the macOS label Aug 29, 2015
@nathany nathany self-assigned this Aug 29, 2015
@omeid
Copy link

omeid commented Aug 29, 2015

The example doesn't check if watcher.Events is closed, so after calling watcher.Close() the outer select would block forever, assuming there are no errors.

@pquerna
Copy link

pquerna commented Apr 13, 2016

I was having similar issues on OSX, and PR #124 fixed them for me.

@nhooyr
Copy link
Contributor

nhooyr commented Jan 10, 2018

I believe this is fixed in #230 @nathany so closing.

@nhooyr nhooyr closed this as completed Jan 10, 2018
@nhooyr
Copy link
Contributor

nhooyr commented Jan 10, 2018

Never mind, seems unrelated if the OP is following the example code.

@nhooyr nhooyr reopened this Jan 10, 2018
arp242 added a commit that referenced this issue Aug 1, 2022
The timeout for unix.Kevent() is causing issues; every 100ms it will do a new
unix.Kevent() syscall, which isn't too efficient: even if you have just one
change an hour, you will still keep calling kevent() ten times per second,
resulting in a needlessly high CPU usage.

Without a timeout, kevent() will block indefinitely until there are some events,
which is much more efficient. We can't just remove the timout however, since we
can't interrupt the kevent() call on FreeBSD and NetBSD, and it will hang
forever. This issue is described in more detail here:
#262 (comment)

To solve this we register a new kevent() with the file descriptor set to the
closepipe; when this pipe is closed an event is sent and kevent() will stop
blocking.

This is a rebased version of #124.

Fixes #89
Fixes #237
Fixes #333
Supersedes and closes #124
Supersedes and closes #262
Supersedes and closes #334
arp242 added a commit that referenced this issue Aug 6, 2022
The timeout for unix.Kevent() is causing issues; every 100ms it will do a new
unix.Kevent() syscall, which isn't too efficient: even if you have just one
change an hour, you will still keep calling kevent() ten times per second,
resulting in a needlessly high CPU usage.

Without a timeout, kevent() will block indefinitely until there are some events,
which is much more efficient. We can't just remove the timout however, since we
can't interrupt the kevent() call on FreeBSD and NetBSD, and it will hang
forever. This issue is described in more detail here:
#262 (comment)

To solve this we register a new kevent() with the file descriptor set to the
closepipe; when this pipe is closed an event is sent and kevent() will stop
blocking.

This is a rebased version of #124.

Fixes #89
Fixes #237
Fixes #333
Supersedes and closes #124
Supersedes and closes #262
Supersedes and closes #334

Co-authored-by: Felix Lange <fjl@twurst.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants