code review 5248062: exp/kevent: implements a wrapper for the BSD kevent/kqu...

exp/kevent: implements a wrapper for the BSD kevent/kqueue system.

This is meant to be a file watcher package for BSD systems.
See os/inotify for a similar package on Linux systems.

[howeyc, 2011-10-12 14:08:12]

Hello dave@cheney.net (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[hector, 2011-10-13 12:57:31]

I think it will be necessary to define a common interface to the file watcher
systems across the various OSes.  I tried to submit a change to implement file
watching for Windows and rsc prompted that we should be doing this.  Can we try
to hammer out a proposal for such an interface on golang-dev?  The reference to
my changelist is http://codereview.appspot.com/4188047/.

[howeyc, 2011-10-13 13:37:21]

On 2011/10/13 12:57:31, hector wrote:
> I think it will be necessary to define a common interface to the file watcher
> systems across the various OSes.  I tried to submit a change to implement file
> watching for Windows and rsc prompted that we should be doing this.  Can we
try
> to hammer out a proposal for such an interface on golang-dev?  The reference
to
> my changelist is http://codereview.appspot.com/4188047/.

That sounds like a good idea to me. I was actually thinking about a unified file
monitoring package for all supported OSs, but I don't have a windows or linux
box to test those platforms. It looks like you have a windows box based on your
changelist, and I can get a Linux box up and running pretty quick if you don't
have one, as we'll need to modify its interface a bit to make a common API.

Are you thinking of starting another thread to talk about the interface? Here
are my thoughts that you can use/disregard if you start one:

Create a FileEvent type similar to FileInfo returned from Stat() that has common
functions between OSs (Path(), IsDelete(), IsWrite(), ...)

As we cannot push an interface over a channel I was thinking we may need to make
a blocking NextFileEvent() (FileEvent, Error) function with simple code (not
valid, off the top my of head):

func Nextfileevent(watch w) ( fileevent, error) {
   select {
      case err := <-w.Error:
      case event := <-w.Event:
   }
   return event, err
}

The channels would then become private.

I'm also thinking of removing an external facing AddWatch(name, flags)
as the flags are OS dependent, just have AddWatch(name) as an external function
that adds all flags. The user of package can use the interface functions of
FileEvent to disregard the events they don't care about. Also, removing the flag
consts from being public would be something to discuss.

I'd also like to change the package name from inotify to something more
OS-agnostic, perhaps filemon or filewatch? I'm not attached to any name in
particular, I'm okay with whatever others feel is appropriate.

[rsc, 2011-10-13 13:50:56]

Thanks for working on this.  I agree with Hector that we
need to figure out an API that works for all the systems.
However, trying to design the API without code to look at
has not worked in the past, so let's try something else.
Please change the CL to make this package exp/kevent,
and we'll move os/inotify to exp/inotify, and then we
can have Windows's exp/whatever, and then once all three
are there it will be easier to compare APIs and decide
what the eventual, mostly portable os/fsnotify should be.

Thanks.
Russ

[rog, 2011-10-13 15:15:50]

On 13 October 2011 14:37,  <howeyc@gmail.com> wrote:
> As we cannot push an interface over a channel [...]

er, why not?

[howeyc, 2011-10-13 15:34:17]

On 2011/10/13 15:15:50, rog wrote:
> On 13 October 2011 14:37,  <mailto:howeyc@gmail.com> wrote:
> > As we cannot push an interface over a channel [...]
> 
> er, why not?

in my head I was thinking of something like this...
http://groups.google.com/group/golang-nuts/browse_thread/thread/71bba09a30918...

[howeyc, 2011-10-13 15:45:32]

Hello dave@cheney.net, hectorchu@gmail.com, rsc@golang.org, rogpeppe@gmail.com
(cc: golang-dev@googlegroups.com),

Please take another look.

[bradfitz, 2011-10-13 15:55:50]

Just to bikeshed,

I think kevent, inotify, etc should be:

syscall/inotify
syscall/kevent

exp/ works for now, but I never want to see these graduate out of exp/ into
somewhere suggesting they're portable (which to me means anywhere that's not
syscall)

Both the names os/inotify and exp/kevent make me a bit uncomfortable.


On Thu, Oct 13, 2011 at 8:45 AM, <howeyc@gmail.com> wrote:

> Hello dave@cheney.net, hectorchu@gmail.com, rsc@golang.org,
> rogpeppe@gmail.com (cc: golang-dev@googlegroups.com),
>
> Please take another look.
>
>
>
http://codereview.appspot.com/**5248062/<http://codereview.appspot.com/5248062/>
>

[rsc, 2011-10-13 16:00:34]

Let's bikeshed later.  I don't see a point to syscall/whatever
if we can just have one portable API.  We don't have syscall/epoll
syscall/select etc.  We just have net.

[bradfitz, 2011-10-13 16:03:50]

On Thu, Oct 13, 2011 at 9:00 AM, Russ Cox <rsc@golang.org> wrote:

> Let's bikeshed later.  I don't see a point to syscall/whatever
> if we can just have one portable API.  We don't have syscall/epoll
> syscall/select etc.  We just have net.
>

Yeah, agree that'd be ideal.

[rcostu, 2011-10-20 17:57:59]

On 2011/10/13 16:03:50, bradfitz wrote:
> On Thu, Oct 13, 2011 at 9:00 AM, Russ Cox <mailto:rsc@golang.org> wrote:
> 
> > Let's bikeshed later.  I don't see a point to syscall/whatever
> > if we can just have one portable API.  We don't have syscall/epoll
> > syscall/select etc.  We just have net.
> >
> 
> Yeah, agree that'd be ideal.

I asked yesterday on go-nuts list something like this to be done and Hector
redirected me here.

I've been thinking for a while and I have taken a look to exp/winfsnotify,
exp/inotify and this patch. I think that a common interface API could be done,
although I don't know a lot about Notifying system on Windows and its
implementation differs somehow from inotify/kevent.

I'd rather rebuild the package and wrap it under os/fsnotify or os/nodenotify.

Could I start trying to do some code about it to further discuss over the final
interface? Is there anywhere else an opened discussion on this topic?

[howeyc, 2011-10-20 21:02:03]

On 2011/10/20 17:57:59, rcostu wrote:
> I asked yesterday on go-nuts list something like this to be done and Hector
> redirected me here.
> 
> I've been thinking for a while and I have taken a look to exp/winfsnotify,
> exp/inotify and this patch. I think that a common interface API could be done,
> although I don't know a lot about Notifying system on Windows and its
> implementation differs somehow from inotify/kevent.
> 
> I'd rather rebuild the package and wrap it under os/fsnotify or os/nodenotify.
> 
> Could I start trying to do some code about it to further discuss over the
final
> interface? Is there anywhere else an opened discussion on this topic?

I started working on it and submitted my take on a possible os/fsnotify here:
http://codereview.appspot.com/5304046/

It's really up to the community if what I submitted is the chosen direction and
whether or not it's in a format that Windows functionality can be integrated to
provide a consistent interface.

[rsc, 2012-06-03 04:33:34]

removing reviewer list