Date: Sun, 14 Jan 2024 09:30:07 -0700 From: Alan Somers <asomers@freebsd.org> To: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= <vini.ipsmaker@gmail.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-threads@freebsd.org, Konstantin Belousov <kib@freebsd.org> Subject: Re: aio_read2() and aio_write2() Message-ID: <CAOtMX2h7vmwKHWUm7aHAfJ0QGPYfaWUmriu%2BxpwA2yK8O2YOoA@mail.gmail.com> In-Reply-To: <CAK9Rve%2BuYpxWyRPwh6gxjRkisU7WPKjXicU9%2BYiqFG-=c3trvg@mail.gmail.com> References: <CAOtMX2haq%2BErvqD2PDYKUGRgdCrk2SDjtoPL-W5jR8q8_4denA@mail.gmail.com> <CAK9RveJLK9uU0twM%2BKznUNnUnsqzwoqidPN8dzNptMQ50Z7r1Q@mail.gmail.com> <CAOtMX2ijQ=KsccMyqH-yAn6SJPR7MD_yy6CF0R2vNrQ-fhUq2Q@mail.gmail.com> <ZaMsUn8xFKrDkJb_@kib.kiev.ua> <CAK9Rve%2BuYpxWyRPwh6gxjRkisU7WPKjXicU9%2BYiqFG-=c3trvg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 13, 2024 at 5:51=E2=80=AFPM Vin=C3=ADcius dos Santos Oliveira <vini.ipsmaker@gmail.com> wrote: > > Em s=C3=A1b., 13 de jan. de 2024 =C3=A0s 21:35, Konstantin Belousov > <kostikbel@gmail.com> escreveu: > > In principle the function of the new flag could be done like > > aio.aio_offset =3D 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2h7vmwKHWUm7aHAfJ0QGPYfaWUmriu%2BxpwA2yK8O2YOoA>