Re: aio_read2() and aio_write2()
- Reply: Alan Somers : "Re: aio_read2() and aio_write2()"
- In reply to: Alan Somers : "Re: aio_read2() and aio_write2()"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 14 Jan 2024 17:07:34 UTC
Em dom., 14 de jan. de 2024 às 13:30, Alan Somers <asomers@freebsd.org> escreveu: > I don't understand. What are you worried about that would block? > lseek never does. It never actually goes to disk; it just retrieves a > variable from within the kernel. So while the expense of a syscall is > non-zero, you don't have to worry about lseek blocking. Sorry, that was a lot of condensed information that I dumped together. We can use lseek to get the offset and use AIO specifying the offset we just queried. However the untrusted sandboxed process might actually send as a socket file descriptor (we don't control what we get from the untrusted sandboxed process), and lseek is then inappropriate. From what I've read from the source code, we can pass these bogus offsets to AIO, and it'll just work. However we're still paying an extra syscall (and code doesn't feel right anyway). Anyway, the kernel *already* has this thread pool (AIO daemons), and the only change required here is a flag that controls whether FOF_OFFSET is passed along. That's a pretty non-invasive change. What is the problem? Again, the model already works fine on Windows and Linux. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/