From nobody Sun Jan 14 18:23:35 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 4TCkDj31QWz56pMg for ; Sun, 14 Jan 2024 18:23:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (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 4TCkDh3Q4Pz4fnH; Sun, 14 Jan 2024 18:23:48 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.180 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-7835aea8012so40026685a.0; Sun, 14 Jan 2024 10:23:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705256627; x=1705861427; 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=W2fAqpZXcZbCislf9ld2gdLp8RvWbeH4/JUssOhEAvw=; b=EzQ5fFzympe0pY9jwglhdoszBUAhDCA3gUc1VDXbjzS+D+N0AaESNdoz8sLNDm1KrY IfITPPlYVqb5fspFMLL0e4fIaLcyTE9pcD4gE1auIe5ou0uPr0woxyslDLRrgXYWi+NZ 72zPCLIMtDhx5TwXUnoSKKtmWHkrPbpzhLi3l6V0ZoiixeGs9TKpxT7KjxVyG7Qeh4s+ haOULedDLYS+7jYLUghc6WmB6kOi62j46dNYcHoob39oqYYppmbuBoIZYLYR9xowEzSa BU+fPQudPtFKPSVAPaQKOLpe5Q7p80AUAnRz4wwKpeOdOlh1yiwKj5ZnonUtAusiNxzF oJ3Q== X-Gm-Message-State: AOJu0Ywjjf7rbv+NUGApxBdW6NGX5y2t4AfqQkSONVtFQLHiBXxNuCA9 US39kfQcSpvz7HwKAMYc/9iRU4y/Y8Dml/nSS9I7ivCM X-Google-Smtp-Source: AGHT+IHSAx46JZVoNxcYjgByZKwDM8w/6XBWh+ruRIclQ9c0SbJXBEbluo1XYP20sT+fOADwYw8U/ygfVF68u3xU0Yk= X-Received: by 2002:a05:620a:13c1:b0:783:2554:9372 with SMTP id g1-20020a05620a13c100b0078325549372mr5218841qkl.136.1705256627320; Sun, 14 Jan 2024 10:23:47 -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: Alan Somers Date: Sun, 14 Jan 2024 11:23:35 -0700 Message-ID: Subject: Re: aio_read2() and aio_write2() To: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= Cc: Konstantin Belousov , freebsd-threads@freebsd.org, Konstantin Belousov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.88 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.985]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-threads@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MISSING_XM_UA(0.00)[]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.180:from]; TAGGED_RCPT(0.00)[]; FREEFALL_USER(0.00)[asomers]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.180:from] X-Rspamd-Queue-Id: 4TCkDh3Q4Pz4fnH On Sun, Jan 14, 2024 at 10:30=E2=80=AFAM Vin=C3=ADcius dos Santos Oliveira wrote: > > 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? 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. > > 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 = doesn'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. 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? 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). 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. That would be a involved project and it needs a serious design effort. Even then, I suspect that the best solution would be to completely eschew the seek pointer. Instead, all operations would either specify the offset (as with pwrite, pread) or operate only at EoF as if O_APPEND were used. -Alan