Date: Wed, 31 Jan 2024 13:23:02 -0300 From: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= <vini.ipsmaker@gmail.com> To: Alan Somers <asomers@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-threads@freebsd.org, Konstantin Belousov <kib@freebsd.org> Subject: Re: aio_read2() and aio_write2() Message-ID: <CAK9RveKVeUbuvcsC98nYfp-9w0xDx%2BiksT8Ls-3q_bXk6SvS3w@mail.gmail.com> In-Reply-To: <CAK9Rve%2BNNzH88OJRCGeoWfmaaZvahDqgTK82bZ%2BnGPV%2B7wACMg@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> <CAOtMX2gbJ6jBSBdyQuwJqPrwDom25=LgrApCBiy5oFuVXL5nQA@mail.gmail.com> <CAK9RveJ9G4Cbq2pPAbfy_nC9dMtQT-b=xO__0=rzWLiyqZNqLw@mail.gmail.com> <CAOtMX2iWzPvkzpdp4K5VVkWQicyidT2ibF=_==e_PLaRj6s6WQ@mail.gmail.com> <CAK9Rve%2BNNzH88OJRCGeoWfmaaZvahDqgTK82bZ%2BnGPV%2B7wACMg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Do any objections remain for the patch? The workarounds mentioned previously don't work for me (CAP_SEEK required, but I don't control the file descriptors received through SCM_RIGHTS). Em dom., 14 de jan. de 2024 às 16:06, Vinícius dos Santos Oliveira <vini.ipsmaker@gmail.com> escreveu: > > Em dom., 14 de jan. de 2024 às 15:23, Alan Somers > <asomers@freebsd.org> escreveu: > > I think you're using the term "green threading" too broadly. Golang > > uses green threads, but Rust does not. The difference is that in Rust > > with async/await, the task-switching boundaries are explicit (the > > .await syntax). So Rust uses explicit concurrency, not green > > threading. I can't speak to the other languages you mention. > > Still, we might have async IO if the implementation permits. > > > You propose an extension that would essentially create asynchronous > > (and racy) versions of read, write, readv, and writev . But what > > about copy_file_range and fspacectl? Or for that matter all the > > dozens of control-path syscalls like open, stat, chmod, and truncate? > > They would block the thread, obviously. Look, I've been playing with > async IO for most of my career. I'm not asking for exoteric APIs. I > just want a non-blocking version for read(). What's so hard about > that? From what I understand from FreeBSD source code, I can already > "unofficially" do that (offset is ignored if the concrete type is not > a real file). > > Very very few OSes actually implement async versions for anything > beyond the typical read()/write(). Even open() could block. For > anything beyond read()/write(), you just create a thread and live with > that. From a userspace perspective, it's expected that filesystem > operations such as file-move, directory-listing, etc will block the > thread. It's already expected. However you don't expect that for the > basic read()/write(). > > Again: Linux and Windows already allow that and it works fine on them. > > And again: I ask why FreeBSD is special here. I've been answering your > questions, but you've been avoiding my question every time. Why is > FreeBSD special here? Linux and Windows work just fine with this > design. Why suddenly does it become special for FreeBSD? It's the very > same application. > > > This flag that you propose is not a panacea that will eliminate all > > blocking file operations. There will still be a need for things that > > block. Rust (via the Tokio library) still uses a thread pool for such > > things. It even uses the thread pool for the equivalent of read() and > > write() (but not pread and pwrite). > > Nothing new here. I use thread pools to perform DNS queries. I allow > my user to create threads to perform blocking filesystem operations > (move, directory listing, etc). I know what I'm asking for: a read() > that won't block. I'm not asking for a competitor to io_uring. I'm > just asking for a read() that will never block my thread. > > > My point is that if you want fully asynchronous file I/O that never > > blocks you can't achieve that by adding one additional flag to POSIX > > AIO. > > It's just a read() that won't block the thread. Easy. > > Do you have concrete points for the design? What does it need to > change in the design so it becomes acceptable to you? What are the > criterias? If the implementation fulfills all these points, will it be > acceptable for you? > > > Instead, all operations would > > either specify the offset (as with pwrite, pread) or operate only at > > EoF as if O_APPEND were used. > > I strongly disagree here. Async APIs should just achieve the same > semantics one *already* has when it creates threads and performs > blocking calls. Do *not* create new semantics. The initial patch > follows this principle. Your proposal does not. > > > -- > Vinícius dos Santos Oliveira > https://vinipsmaker.github.io/ -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK9RveKVeUbuvcsC98nYfp-9w0xDx%2BiksT8Ls-3q_bXk6SvS3w>