FileDescriptor.sync isn't using Blocker

[Robert Engels]

My apologies though if the above is not correct as I can’t review your reference to Blocker and the JEP makes no mention. I don’t have east access to the source at the moment. 

> On Jul 13, 2023, at 9:18 AM, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> 
> 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/10b6b78f/attachment.htm>