<div dir="auto">Afaik every I/O (either socket/file-related ones) as executed in place. The file related ones, unless DIRECT_IO is used, are still Vs the OS page cache, which means are not that much slower, although user-kernel-user transition is clearly in place (with its inherent cost). <div dir="auto">AFAIK this could change if io_uring is used because submission ring buffers are not meant to be used concurrently and only socket requests are actually executed in-place (unless specified differently).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il sab 1 giu 2024, 00:44 Robert Engels <<a href="mailto:robaho@me.com">robaho@me.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
An interesting question came up on the Go support channels. One of the principle engineers stated that for local file IO, the Go routine (similar to virtual thread) won’t release the carrier thread.<br>
<br>
Is this the same with Java virtual threads? Yes, local IO is typically fast - but it is still order of magnitudes slower than memory computations - which the virtual thread could be doing while waiting for the IO request to be serviced.<br>
<br>
R</blockquote></div>