Skip to content
This repository has been archived by the owner on Jun 8, 2022. It is now read-only.

Write Events/Errors using select #7

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

Write Events/Errors using select #7

howeyc opened this issue Jun 6, 2012 · 9 comments

Comments

@howeyc
Copy link
Owner

howeyc 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
Copy link
Contributor

nathany commented Sep 4, 2013

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

@howeyc
Copy link
Owner Author

howeyc 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 mentioned this issue Nov 30, 2013
9 tasks
@nathany
Copy link
Contributor

nathany commented Jan 16, 2014

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

@aktau
Copy link

aktau 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
Copy link
Contributor

nathany 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
Copy link

aktau 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
Copy link

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
Copy link
Contributor

nathany commented Mar 18, 2015

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

@matthewmueller
Copy link

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

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

bronger added a commit to bronger/watchdog that referenced this issue May 23, 2021
For some very obscure reason (or let's call it "badly explained"), the reading
from the event and error channel should take place in a separate goroutine.
See howeyc/fsnotify#7 for a discussion about it.
Apparently, something may block if done otherwise.

Although all material about this topic fails to give a code example that
exhibits this problem, I obey and put the events reader into its own goroutine.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants