deadlock about fsnotify

[howeyc]

Interesting, may have something to do with Closing and then opening another watch.
What OS are you using? Or does it happen on multiple?

[skelterjohn]

This happened on linux. I also have a mac I can test this on - I'll get back to you.

[skelterjohn]

It's not an issue on os x.

[howeyc]

Sorry I don't have time to test right now, but if you have time, could you try and drain the Event and Error channels after close (do a for range on them)?

If not, I'll try something later.

If my intuition is right and that stops the deadlock I can work on a proper fix.

[skelterjohn]

I am unable to reproduce the problem on this linux machine (yay?) When I get home I'll test again on the machine where I saw the problem, and let you know. Maybe I'm an idiot - it happens.

[skelterjohn]

On my home machine this appears not to help.

[howeyc]

Okay, I'm having trouble finding the issue, let's review:

Are you monitoring both the Event and Error channels?

ex:

go func() {
    for event := range w.Event {
        log.Print(event)
    }
}()
go func() {
    for err := range w.Error {
        log.Print(err)
    }
}()
/* ... do stuff ... */
w.Close()

Also, just in case, please try latest change I made.

If this doesn't help, would you perhaps be willing to give more context (ie, more lines of code) so I can better trouble shoot the issue.

[skelterjohn]

Draining the events and errors in a separate goroutine seems to have fixed
the issue.

On Tue, May 22, 2012 at 10:30 AM, Chris Howey <
[email protected]

wrote:

Okay, I'm having trouble finding the issue, let's review:

Are you monitoring both the Event and Error channels?

ex:

go func() {
   for event := range w.Event {
       log.Print(event)
   }
}()
go func() {
   for err := range w.Error {
       log.Print(err)
   }
}()
/* ... do stuff ... */
w.Close()

Also, just in case, please try latest change I made.

If this doesn't help, would you perhaps be willing to give more context
(ie, more lines of code) so I can better trouble shoot the issue.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[howeyc]

Great!

I'll update the README to make it clear that you must watch Error and Event channels in separate go routine.

Thanks.

[skelterjohn]

I don't know if that's the best solution - it should be possible to make it
so there is no deadlock there in any context.

On Tue, May 22, 2012 at 10:56 AM, Chris Howey <
[email protected]

wrote:

Great!

I'll update the README to make it clear that you must watch Error and
Event channels in separate go routine.

Thanks.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[howeyc]

I'll take a look, but once channels are involved it's kind of difficult to do so.

Once I attempt to write to a channel, and you are not reading from it, well... you know what happens.

[skelterjohn]

Instead of:
for {
ch <- something
}

You'd do:
loop:
for {
select {
case ch <- something:
case <-stopSending:
break loop
}
}

and when .Close() was called, you'd send a value on stopSending.

[daaku]

fwiw, I also tripped up on this. It would be nice if it wasn't required to read from the channel in a separate goroutine.

[howeyc]

Yeah... I understand.

Hopefully it wont take me too long to find the time and make the required changes.

Thanks for the input.

[skelterjohn]

Thanks for the nice cross-platform notify lib! Very useful.

[daaku]

+1 -- thanks for writing this and making it available!