WatchService - Exposing more of the Inotify Event Model

[Rémi Forax]

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 
the user
to choose what he want to store by adding a kind of attachment object 
similar to
the one used for the Selector/SelectionKey mechanism.

Rémi

>
>
>
> 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
>     models.
>
>     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
>     LinuxWatchEventKind.java.
>
>     Regards
>
>     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.
>     After
>     > looking at the JDK7 source code it was clear to me a lot of hard
>     work
>     > 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
>     silver
>     > bullet to my particular project--but as the link Rémi provided
>     points
>     > 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
>     >>>
>     http://forums.java.net/jive/thread.jspa?threadID=152825&tstart=0
>     <http://forums.java.net/jive/thread.jspa?threadID=152825&tstart=0>
>     >>>
>     <http://forums.java.net/jive/thread.jspa?threadID=152825&tstart=0
>     <http://forums.java.net/jive/thread.jspa?threadID=152825&tstart=0>>
>     >>>
>     >>> 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
>     example,
>     >>> Inotify on the Linux platform provides additional events not
>     currently used
>     >>> by the LinuxWatchService implementation such as: IN_ACCESS,
>     IN_CLOSE_WRITE,
>     >>> IN_CLOSE_NO_WRITE, and IN_OPEN.
>     >>>
>     >>> I gave one example at the above URI where an event like
>     IN_CLOSE_WRITE
>     >>> 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
>     defined
>     >> 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
>     modifier
>     >> (com.nio.file.ExtendedWatchEvent)  that might help show you how
>     additional
>     >> 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
>     >> [1].  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
>     entities.
>     >> That might not be a concern in your environment but just
>     mentioning it.
>     >>
>     >> -Alan.
>     >>
>     >> [1] http://openjdk.java.net/contribute/
>     >>
>     >
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100923/4676c215/attachment-0001.html