WatchService - Exposing more of the Inotify Event Model

[Benedict Elliott Smith]

It *is* fairly easy to store the Watchable as a field in the WatchKey,
except that the WatchKey is created by the WatchService, over which the user
typically has no control - and the default implementations return a WatchKey
that cannot tell you what it is watching (despite obviously having to know
this).

As such, currently (and in the example usages) the user has to insert the
WatchKey that is returned by the WatchService into a map which stores the
Watchable. The problem is that if a different thread registers the Watchable
to the one consuming events from the WatchService, it is possible for a
WatchKey to be returned to the consumer before the map contains it, and
hence the consumer does not know what Watchable it is for.

This seems bad to me.

Even if this weren't the case though, it seems a bit unnecessary to expect
the user to store the Watchable themselves - as you say, it should be easy
to store it in the WatchKey, so I'm not sure why it isn't exposed to the
user? Or am I missing something obvious?



On 23 September 2010 16:40, Rémi Forax <forax at univ-mlv.fr> wrote:

>  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> 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> 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>
>> 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>
>> >>>
>> >>> 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/222088f8/attachment.html