FileDescriptor.sync isn't using Blocker

[Robert Engels]

I don’t think that is correct. From the JEP “ The implementations of these blocking operations compensate for the capture of the OS thread by temporarily expanding the parallelism of the scheduler. ”

The number of OS threads will be expanded to compensate for the blocking call. I believe the call to fd.sync() ends up being no different than an arbitrary native call. The same actions occur. 

> On Jul 13, 2023, at 8:28 AM, Brian S O'Neill <bronee at gmail.com> wrote:
> 
> An application which relies on a non-virtual thread pool can spin up more platform threads to compensate, and so a sync isn't necessarily an issue. Virtual threads limit the amount of carrier threads they depend on, and so a virtual thread stuck on a sync can prevent other virtual threads from making progress. The internal Blocker class is intended to help compensate for this behavior.
> 
>> On 2023-07-13 07:13 AM, Robert Engels wrote:
>> It is no worse than the current behavior. If it was a platform thread it would block. The virtual threads carrier thread blocks and a new carrier is spawned. So this would only be a performance optimization not a regression against current performance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230713/e0c4eae8/attachment.htm>