[crac] RFR: Linux file system watcher support

[Radim Vansa]

On Tue, 23 May 2023 11:32:45 GMT, joeylee <duke at openjdk.org> wrote:

>> I was hoping that a fastdebug build with assertions on would fail somewhere earlier but it is not the case. I would suspect that since this NULL dereference is happening when the thread already exits there's an earlier event that goes wrong.
>
> Hi @rvansa , thanks for your review. I have updated FileWatcherAfterRestoreTest with a minimal case where the monitor key could be different after restore, and this test will manually  re-register alternative path.
> 
> 
> 
> When closing the notify service automatically simplifies the code, rather than just adding a close/reopen to the watch key management.
> 
> Where this patch could help simplifies code:
> 1. When users are manually managing all keys, this patch could only save them from  a `close()` and `open()` call before and  after checkpoint.
> 2. But some cases close and reopen a watch service could be very troublesome, like this case:
> Notice the `watchservice` could be final for some 3rd party libraries, in that case we can not reopen and assign a new value for watch service. This patch allows user to focus only on keys, which might change after restore.
> 
> 
> import jdk.crac.Core;
> 
> import java.io.IOException;
> import java.nio.file.FileSystems;
> import java.nio.file.WatchService;
> 
> public class Case {
>     private final WatchService watcher;
> 
>     Case() {
>         watcher = createWatcher();
>     }
> 
>     private static WatchService createWatcher() {
>         try {
>             return FileSystems.getDefault().newWatchService();
>         } catch (IOException e) {
>             return null;
>         }
>     }
> }

Hi @joeyleeeeeee97 , Anton found an issue with memory allocation - could you address/react on that one?

-------------

PR Comment: https://git.openjdk.org/crac/pull/72#issuecomment-1618067529