Events that don't poll

[purpleidea]

Hi,

I'm having a look at this lib for possible use in https://github.com/purpleidea/mgmt/ and I noticed:

go-udev/monitor.go

Line 180 in d6b62d5

// Poll the file descriptor

1. Either this spins constantly (busy loop polling) which is unfortunate since I'd like an event based lib or
2. Then if it blocks in unix.EpollWait, then there's a bug because we can't unblock on that with ctx closes, we'd have to wait until it returns.

Either way figured I'd mention it in case you had some thoughts.

Lastly, it's generally uncommon or discouraged to expose a channel as part of the public API. It's more common to return a function that blocks, with a cancel() function to unblock it when you want to close and there isn't an event.

HTH, and thanks for the lib!

PS: Is this still being maintained or actively used anywhere?

[realh]

It's a bit late, but the way I usually solve this sort of problem is to have a short timeout in the poll. Something in the order of 0.1s should be short enough not to cause a problematical delay when cancelling, but long enough to have negligible impact on system load.

A better solution would probably be to create a pipe. The receiving end could be added to the poll, and another goroutine could send a byte down the other end when the context gets cancelled. It's a pity go's epoll bindings don't support that.