From nobody Sun Jan 14 17:30:26 2024 X-Original-To: freebsd-threads@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCj3R13tZz56jrM for ; Sun, 14 Jan 2024 17:30:43 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCj3Q43c9z4Wny; Sun, 14 Jan 2024 17:30:42 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2cd0f4f306fso93444611fa.0; Sun, 14 Jan 2024 09:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705253440; x=1705858240; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QiKT3xpU7a0ewheF6tIAH5xEjTlp4gwOT5mzBWrPuIQ=; b=b3SRHmsn7ht2qeL5PnQBAhoyebZWSQI+x+/RpvtchYo7PKj3L3ODNmIOEISAlmkchB 698iAksSbKZRkOmoOVyiO80lCcu2hqdfTqJK+7XxhUFDUGB18PM1RAVgriKZUM9IQY6H Z79danorfuHyjFyMjqSqpsaFLYQMhDE0zzqXPsQP1KYBtv/8AXeHkeWi1jhkLP1/wWa+ 6LJN2J0ehHaBtNmwTsoUOdbPfE631K1S7tiFWhbXvwDTkmw0wSdwlNkgM2pwTvFf1L2O DDplSTGDztPPBSAoob7Lxd6NAUmWWVOOth4KNxveOxfB1qW/AMnUU6avA6/j+TXZaJsm PwTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705253440; x=1705858240; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QiKT3xpU7a0ewheF6tIAH5xEjTlp4gwOT5mzBWrPuIQ=; b=CVmhJEWF/cjzlAhL4h3/lNoPOTWTqteuMkWr/eFvh4ZtaX6ntbaAINHzxeYM2qmJDx 5ZfsdKgJwlu2jzlfS/LlC97xUEakP06vr2adeNOKViSwe0lO766yEBaJgYj1mdBZmu9F Y18I0ZGVIv5IQ7QLLKl/sTmzf3sd0Go68TGh3GCtEPiZbeOSSs0qub/YD+5kRdemZf6N RuyBrJhkCpq7K654F/G6XOYhwhorP/Qyn3M0zCCupm0Rc2C7k4GFQ45Qay41+NMQMshH 31G1FmHU+Fd59V0urk9xyESCxUwCxO2DazROO2OsF+fPNiEdUNtXL7DnRtxLbp5pu8JV tyGQ== X-Gm-Message-State: AOJu0YwU1z9YTh+Fj4Jz2fbxWS1QDHjh89r2QKpeDIbPZpkWKVpXwUXf Xy6PfYEdAAkJK9AEPLQ6fqbfLP4JxIuFTwFA5aXlA9Dr5lc= X-Google-Smtp-Source: AGHT+IGZ87xC+34TK9I+pKJRjn+CulhidGgVWQtdD0K1KjOwmGCQx5qyMh9bqk25Gc+ey56n57fTJd39eOlZGf02/Dg= X-Received: by 2002:a2e:7819:0:b0:2cc:e379:88bb with SMTP id t25-20020a2e7819000000b002cce37988bbmr1875650ljc.19.1705253439810; Sun, 14 Jan 2024 09:30:39 -0800 (PST) List-Id: Threading List-Archive: https://lists.freebsd.org/archives/freebsd-threads List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= Date: Sun, 14 Jan 2024 14:30:26 -0300 Message-ID: Subject: Re: aio_read2() and aio_write2() To: Alan Somers Cc: Konstantin Belousov , freebsd-threads@freebsd.org, Konstantin Belousov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TCj3Q43c9z4Wny X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] Em dom., 14 de jan. de 2024 =C3=A0s 14:13, Alan Somers escreveu: > 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. There are two things here: Boost.Asio, and applications built on top of Boost.Asio. I can't speak for other applications built on top of Boost.Asio. With that in mind, let me proceed. There is nothing unusual about my application. I just built an execution context that implements the green threading model. That's nothing unusual about that. NodeJS, Python's asyncio, Rust's asyncio, Golang, luvit, and so on and so on. All these frameworks just mimic interfaces from the blocking world (e.g. two threads doing a blocking read() on two different files become two fibers doing a read() within the same thread). If anything, the whole world is moving to this model after NodeJS proved its usefulness. So what's unusual about that? To clarify: I don't have a single in-flight operation at a time. The same thread dispatches IO requests for different streams (sockets and files). AIO is not only useful for batching operations (on the same file). AIO is also useful for a batch of IO operations on different files. File IO is always =E2=80=9Cready=E2=80=9D and the readiness model do= esn't work for files. On Linux, I can just use io_uring (proactor/completion model) for everything (as in it won't prevent me from skipping an explicit offset). Same with Windows (IOCP). What is special about FreeBSD here? POSIX AIO by itself is useless to me. It's only useful to me with BSD extensions (SIGEV_KEVENT for kqueue integration). I don't see a reason why it can't have another small extension that is pretty much non-invasive. --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/