FileDescriptor.sync isn't using Blocker

[Brian S O'Neill]

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.


On 2023-07-12 09:58 AM, Alan Bateman wrote:
> On 02/07/2023 00:30, Brian S O'Neill wrote:
>> I noticed that FileChannelImpl.force calls Blocker.begin in order to 
>> be virtual thread friendly, but I don't see a corresponding call in 
>> FileDescriptor.sync. Is it not necessary or was it just missed?
> 
> No reason, it could do the same, it's mostly that only the very old APIs 
> that provide a way to get their FileDescriptor. Have you encountered 
> something that may potentially run in a virtual thread that uses this or 
> was it as you say, just noticed it.
> 
> -Alan