Re: aio_read2() and aio_write2()
- Reply: Vinícius_dos_Santos_Oliveira : "Re: aio_read2() and aio_write2()"
- In reply to: Vinícius_dos_Santos_Oliveira : "Re: aio_read2() and aio_write2()"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 14 Jan 2024 16:30:07 UTC
On Sat, Jan 13, 2024 at 5:51 PM Vinícius dos Santos Oliveira <vini.ipsmaker@gmail.com> wrote: > > Em sáb., 13 de jan. de 2024 às 21:35, Konstantin Belousov > <kostikbel@gmail.com> escreveu: > > In principle the function of the new flag could be done like > > aio.aio_offset = lseek(fd, 0, SEEK_CUR); > > aio_read(&aio); > > with the dis-advantage of requiring two syscalls instead of one. > > There are more disadvantages besides the extra syscall. > > I've built a green threading framework for Lua on top of Boost.Asio. > However I also added support for sandboxed actors (capsicum and jails > on FreeBSD). For file descriptors received through SCM_RIGHTS from > sandboxed processes, I really don't want to risk blocking the thread > (DoS) going through O_NONBLOCK (file IO is always ready, and that's > why AIO exists). So, for these file descriptors (one can never know > their "type"... whether they refer to pipes and O_NONBLOCK is enough, > or they refer to files and AIO should be used), I'll use AIO as well. > On Linux I can get away by just using io_uring for everything. 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.