Date: Sun, 14 Jan 2024 10:13:43 -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: <CAOtMX2gbJ6jBSBdyQuwJqPrwDom25=LgrApCBiy5oFuVXL5nQA@mail.gmail.com> In-Reply-To: <CAK9RveK-sjLxCkKpkSTYkecRQVwT%2BuoOSsaW3xD130Hnwb=cog@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> <CAOtMX2h7vmwKHWUm7aHAfJ0QGPYfaWUmriu%2BxpwA2yK8O2YOoA@mail.gmail.com> <CAK9RveK-sjLxCkKpkSTYkecRQVwT%2BuoOSsaW3xD130Hnwb=cog@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 14, 2024 at 10:07=E2=80=AFAM Vin=C3=ADcius dos Santos Oliveira <vini.ipsmaker@gmail.com> wrote: > > Em dom., 14 de jan. de 2024 =C3=A0s 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. In that case, I believe lseek should return ESPIPE. >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. The problem is that this flag would be almost impossible to use correctly for the intended use cases of POSIX AIO. Your application is actually pretty unusual in that it only has one operation in-flight at a time. I think it would be better to use the lseek solution rather than add a footgun to POSIX AIO. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2gbJ6jBSBdyQuwJqPrwDom25=LgrApCBiy5oFuVXL5nQA>