[crac] RFR: Handle open file descriptors with configurable policies [v9]

[Radim Vansa]

On Tue, 4 Jul 2023 16:33:00 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> This does not work; when creating the FileChannel (lazy) as an attempt to read the position I would create another JDKFileResource, and try to register it => this would get blocked as we're already in the FDs priority.
>> 
>> I could probably add in some exceptions to not create it on this codepath, but is it really worth it? I thought that the idea was to work we already have in the resource. And there's no difference in behaviour unless someone appends to that file during checkpoint.
>
> Implicit change of append mode from false to true will surprise users of the channel. E.g. after automatic re-open, the position setting won't take effect anymore, while it was possible if the FOS was created in non-appending mode.
> 
> I'm fine to implement automatic re-opening only FOS originally opened with append. In general, re-opening a file in non-append will also require (optional) verification the file has not been changed, which may be pretty complex, so I don't think it should be implemented now for FOS or other Files.

I was not aware that `lseek` wouldn't work in case the file is re-opened for appending; that really forces us to record the position. Since non-appending mode is the default, I'll try to use another resource with lower priority to create the FileChannel so that it can be used later on by the actual FOS resource.

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

PR Review Comment: https://git.openjdk.org/crac/pull/69#discussion_r1265168749