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

Write Events/Errors using select #7

Open
howeyc opened this issue Jun 6, 2012 · 8 comments

Comments

Projects
None yet
4 participants
@howeyc
Copy link
Owner

commented Jun 6, 2012

This is a request that came up earlier that I almost forgot about. Creating issue so I remember.

Desire is to have the library send events/errors using select so that the receiving application can be monitoring the channels without the use of a separate goroutine.

@nathany

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2013

What would this look like? Same channels/API just without requiring a goroutine?

@howeyc

This comment has been minimized.

Copy link
Owner Author

commented Sep 4, 2013

Yes.
On Sep 4, 2013 12:14 PM, "Nathan Youngman" notifications@github.com wrote:

What would this look like? Same channels/API just without requiring a
goroutine?


Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-23815989
.

@nathany nathany referenced this issue Nov 30, 2013

Closed

Milestones #78

6 of 9 tasks complete
@nathany

This comment has been minimized.

Copy link
Contributor

commented Jan 16, 2014

Chime in for the os/notify API: http://goo.gl/MrYxyA

@nathany nathany referenced this issue Jun 28, 2014

Closed

inotify blocks #5

@aktau

This comment has been minimized.

Copy link

commented Jul 8, 2014

I'm not sure what makes this single thread unfriendly? Why can't I do something like:

func main() {
  // create watcher
  w.Add("./")
  for {
    select {
      case <-w.Events:
        // do stuff
      case <-w.Errors:
        // handle error
      case <-sig:
        // signal received, probably quit
    }
  }
}
@nathany

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2014

See https://code.google.com/p/go/issues/detail?id=8282#c4 for one issue when using code very similar to what you presented.

If you want to take a closer look on multiple platforms, please report your findings at https://github.com/fsnotify/fsnotify/issues/new

@aktau

This comment has been minimized.

Copy link

commented Jul 8, 2014

Right. I suppose this is only an issue on some platforms (old linux? I saw some mentioning of the lowest linux denominator being too low to stop this from happening). Anyway, I'll run it in a separate goroutine for the time being and monitor this space. I'd love to be able to safely use it in single-threaded mode. As it stands, it's not very obvious one needs to do this goroutine trick. Thanks for the update!

@srinathh

This comment has been minimized.

Copy link

commented Mar 15, 2015

At GopherCon India last month, Alan Shreve gave a talk on Principles of designing Go APIs with channels which i thought might be relevant for this issue in FSNotify since I too had to puzzle through the sources to check if it's using blocking channels... Specifically An API that sends an unbounded stream of values into a channel must document how it behaves for slow consumers

@nathany

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2015

@srinathh Thanks for the tip. Now that the videos are up, I'll be sure to watch that talk.

mcauto referenced this issue in mattdamon108/gw May 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.