WatchService - Exposing more of the Inotify Event Model
forax at univ-mlv.fr
Thu Sep 23 08:40:35 PDT 2010
Le 23/09/2010 16:43, Benedict Elliott Smith a écrit :
> While on the topic of the WatchService API, I wonder if there are any
> plans to modify the WatchKey to include a method for retrieving the
> object/path it is watching.
The Watchable ? Why ?
> The fact that it does not introduces a race condition, whereby the
> WatchService can return a WatchKey before the thread registering the
> key has a chance to put the key in a map containing this information.
I think I don't understand.
It's easy to store the watchable in a field of the watch key.
I wonder if instead of storing a watchable, it's perhaps better to allow
to choose what he want to store by adding a kind of attachment object
the one used for the Selector/SelectionKey mechanism.
> On 23 September 2010 07:41, fm <fudmail at gmail.com
> <mailto:fudmail at gmail.com>> wrote:
> I've modified a few of the WatchService implementation classes to
> allow for the registration of additional WatchEvent.Kind instances
> that represent the native events of the underlying OS platform. I
> believe the changes add flexibility to the WatchService API, with
> minimal disruptive code changes to the existing implementation. There
> should be a negligible impact on the existing performance. I have
> altered the implementation of the LinuxWatchService to support the
> additional event model; however, the SolarisWatchService and
> WindowsWatchService implementations are effectively unchanged and
> should work the same as before. Similar modifications could be made to
> these WatchService implementations to also expose their native event
> I am completely open to hearing comments on if this type of added
> flexibility to the WatchService API is appropriate for the JDK 7 or
> better left to an ex
> ternal project.
> I will gladly provide the source code files for evaluation if there is
> interest. Modified files are AbstractWatchKey.java,
> AbstractPoller.java, LinuxWatchService.java, and one new file
> On Thu, Sep 2, 2010 at 10:59 AM, fm <fudmail at gmail.com
> <mailto:fudmail at gmail.com>> wrote:
> > Thank you for the response. This is the type of info I was looking
> > for. Reading the WatchService related API documentation I got the
> > sense it was designed for extension. After skimming over some of the
> > related source code, it wasn't yet clear to me the best way to go
> > about accessing the additional Linux specific filesystem events.
> > looking at the JDK7 source code it was clear to me a lot of hard
> > went into the design of the WatchService notification capability and
> > it would be a shame not to be able to leverage it for accessing
> > additional event tyeps. I will look into you suggestions.
> > I am also aware that Inotify's IN_CLOSE_WRITE event is not the
> > bullet to my particular project--but as the link Rémi provided
> > out, it may be more suitable that IN_MODIFY (in my case as well as
> > others). But I believe you are correct also that one cannot assume
> > something else does not have a file open for writing...it is
> just much
> > more unlikely in my particular case.
> > Regards
> > On Thu, Sep 2, 2010 at 8:00 AM, Alan Bateman
> <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
> >> f m wrote:
> >>> Per Alan B.'s request, I'm moving a discussion here that was
> started at
> >>> I'll try to summarize.
> >>> A useful goal of the JDK7 WatchService is to provide a uniform
> file system
> >>> event facility across multiple operating systems. However, in
> some cases, it
> >>> may be more desirable to give up the portability in order to
> tap into the
> >>> full expressiveness of the event model of the native OS. For
> >>> Inotify on the Linux platform provides additional events not
> currently used
> >>> by the LinuxWatchService implementation such as: IN_ACCESS,
> >>> IN_CLOSE_NO_WRITE, and IN_OPEN.
> >>> I gave one example at the above URI where an event like
> >>> could be used to detect and process a large file only after it
> has been
> >>> completely copied into a watch directory.
> >>> After looking over the internal LinuxWatchService.java source
> code, it
> >>> appears that the implementation could be readily used
> (modified or resused?)
> >>> to also provide access to these additional event types.
> Another event class
> >>> representation like LinuxWatchEventKinds would need to be
> added and used
> >>> alternatively to the StandardWatchEventKinds.
> >>> My question. Would extending the LinuxWatchService capability to
> >>> optionally expose the greater set of Inotify event types be in
> scope for JDK
> >>> 7 development, or will client developers who desire this
> capability need to
> >>> find 3rd party implementations (or develop it themselves)?
> >>> Regards.
> >> The API is designed to allow for events and modifiers that are
> >> beyond the javadoc so provider implementations can include
> support for other
> >> events if they wish. We haven't included any support for other
> events in the
> >> JDK because our primary motive has been to help the performance of
> >> applications that are forced to poll the file system today. If
> you are
> >> looking for pointers then there is one implementation specific
> >> (com.nio.file.ExtendedWatchEvent) that might help show you how
> >> support is included. You are welcome to hack on the code and
> try out
> >> additional events but you have to be a contributer to
> contribute patches
> >> . A small comment on the "close after write" event is that
> I don't think
> >> you are guaranteed that the file isn't being modified by other
> >> That might not be a concern in your environment but just
> mentioning it.
> >> -Alan.
> >>  http://openjdk.java.net/contribute/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nio-dev