WatchService - Exposing more of the Inotify Event Model
Rémi Forax
forax at univ-mlv.fr
Thu Sep 23 10:11:32 PDT 2010
Le 23/09/2010 17:45, Benedict Elliott Smith a écrit :
> 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).
Ok.
As I said, I think a more general attached Object is a better solution
in my opinion.
>
> 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.
If you store/retreive the path in a synchronized block or use a
ConcurrentHashMap
and call put() before registering, I don't see why there is a problem ?
>
> 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?
It's not exposed because the current implementation doesn't store it :)
On Linux the file descriptor is stored not the corresponding Path.
Rémi
>
>
>
> On 23 September 2010 16:40, Rémi Forax <forax at univ-mlv.fr
> <mailto: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
>> <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/95602461/attachment-0001.html
More information about the nio-dev
mailing list