WatchService questions

[Alan Bateman]

Sebastian Sickelmann wrote:
> I think both solutions (Implementation 2A and 2B) are only realy good in multithreaded environments. When there is only 
> one other programm or thread that writes to the watched Directory Implementation 1 will be faster.
> The order of the MODIFY-EVENTS of different contexts are than relative to the ==first== Modification of the contexts.
>   
If you have cycles to experiment and send results that would be great. 
Also it's good to think about different scenarios where there is one or 
several programs changing files. One thing to mention about our 
implementations is that the 3 native implementations use a single poller 
thread per watch service. So if you are hacking on 
AbstractWatchKey.signalEvent then there will be only one producer. The 
polling implementation could potentially have concurrent threads polling 
directories but they will be different directories (never the same 
directory) and events are queued on per watch key basis so again only 
one producer.

> But what should be done with other Events than StdWatchEventKind?
>   
Our implementation does support a non-standard modifier when registering 
events but it doesn't support any additional events at this time. For 
now, it is okay to focus only on ENTRY_MODIFY events and assume that you 
can't reorder other events.

-Alan.