Write Events/Errors using select

[howeyc]

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]

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

[howeyc]

Yes.
On Sep 4, 2013 12:14 PM, "Nathan Youngman" [email protected] 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]

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

[aktau]

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]

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]

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]

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]

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

[matthewmueller]

Is this still an issue? golang/go#8282 (comment)

If so, what would be the non-racey way of doing this?