Virtual threads and File IO

[Robert Engels]

Agree. It was only offered as evidence that async handling can offer huge rewards. Since the case study distinguished between socket and file async it was a good example imo.

> On Jun 3, 2024, at 9:28 AM, Pedro Lamarão <pedro.lamarao at prodist.com.br> wrote:
> 
> Linux sendfile and Windows TransmitFile are very specific beasts.
> If you are sending files to sockets, yes, that should be the best the system can do.
> For general file I/O in Linux, the API called AIO with aio_read and aio_write is no good.
> These communicate completion asynchronously via UNIX signals.
> Linux I/O rings seem to be the way forward, but do not seem ready for general production yet.
> Some cloud providers disable it because of a history of security bugs.
> Pedro.
> 
> Em seg., 3 de jun. de 2024 às 11:06, Robert Engels <robaho at icloud.com <mailto:robaho at icloud.com>> escreveu:
> Here is an interesting case study on async file IO under Linux http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-and-linux-aio/ <http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-and-linux-aio/>
> 
> > On May 31, 2024, at 6:22 PM, robert engels <robaho at icloud.com <mailto:robaho at icloud.com>> wrote:
> > 
> > I looked into the code. Seems Java is the same. I looked into it - and seems for many workloads async file IO can improve efficiency by 80%. 
> > 
> >> On May 31, 2024, at 5:45 PM, Robert Engels <robaho at me.com <mailto:robaho at me.com>> wrote:
> >> 
> >> Hi,
> >> 
> >> 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.
> >> 
> >> 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.
> >> 
> >> R
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240603/d1a0431a/attachment.htm>