FileDescriptor.sync isn't using Blocker

[Alan Bateman]

On 12/07/2023 18:12, Brian S O'Neill wrote:
> I was studying how blocking file operations are handled by virtual 
> threads, and then I was curious if there any edge cases that were 
> missed. Even though FD.sync is an old operation, I do tend to use it 
> quite a bit (it's convenient), and a quick search showed that a lot of 
> other projects use it as well.
>
> I've not observed any real issue with virtual threads and FD.sync, but 
> it seems like it could be an issue considering that the sync operation 
> can take a very long time, sometimes taking several minutes on a 
> heavily loaded file system.
>
> In my specific case, the sync operation could run in a virtual thread, 
> because I have no control over what thread might indirectly invoke it. 
> Switching to use the FileChannel to sync isn't a big deal, but I'd 
> rather not have to worry about such things.

You shouldn't need to worry about it, it will run just fine in a virtual 
thread, it just doesn't currently compensate so doesn't smooth over the 
temporary pinning. A static analysis of 485k libraries didn't find a lot 
of usage, at least not compared to all the other blocking I/O, probably 
not too surprising as the FileDescriptor can only be obtained from a 
small number of APIs (those that date from early JDK releases). We can 
include it in the next update but eventually it will be replaced as we 
want operations like this to release the carrier to do other work.

-Alan