From nobody Sun Jan 14 19:06:50 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 4TClBh28v5z56vFG for ; Sun, 14 Jan 2024 19:07:08 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 4TClBg5tZpz4nwb; Sun, 14 Jan 2024 19:07:07 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2cd1ca52f31so92426351fa.3; Sun, 14 Jan 2024 11:07:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705259224; x=1705864024; 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=g6e8AxzsL1Z7+UnB0N4e7wU9qJxc05VReqPIxkUBWmQ=; b=ljKNPduyk+2ImratCZr4hkQPhVqmruMeOtuUOOtBxZ/RN9vAo+0Q/rg5RQ1YvhW6KF 0OTrlyArDWotBVA+kw5ZqyDggntAmN1qhh0LX3mJFeEgxE8PHu+qrmikZdTz5i1q4oWM vcqYmuWkolNke5HDfxDJsw2iuS6MK1AhMdu539Uk+YDRXpGmkCqGZ8CjE7Qxx/gX01Hk UV5bzRZbUeHQXPMp69gKuywumG9olYhcxOdKSjnQNmqaFtxIvhBJhGxmnEX0g/DbsO27 6P5Q1PaLl4HsiKCQE64wGbQo5kaJPEidsgp+l/pNP5dSAxXvKFij5V1IuAwqYCltXGD5 ccmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705259224; x=1705864024; 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=g6e8AxzsL1Z7+UnB0N4e7wU9qJxc05VReqPIxkUBWmQ=; b=LzlquDzufPQsh2LPIJPW2Kj9gpujisfix0Qie3vYrb9VtxBsi8Bge71kmo2hKkSNbI smdzUpyNCsa8clLCysE8mMDtBpwR1729TEh3b7H/1fc/qsJd80jmd6nfn4UMP2ny2rOc Z9s+GzMytJNxrz6JcvvCz0HnZ3kvv/vXPOMWfPduiB+0Jjx01QwL6NlbPL9ZXQjDOkXN PfCASPccWfDMVkaiTO7IzO7+6rwJ0o1lDTilQIWJpAIF6XC6rmpuf71kReew8WgmaeBn 8nYcfJ30wrFfuHHOOxFAEflHnZY4oWeXkSyhjgnAjtPqhOIICzVoRlHhIAvSAeHc+qS3 FYVA== X-Gm-Message-State: AOJu0YzLCrm4SEvNmNgYUMz9pW+LwlAAMM4K6IgnRaqV7YKnUDAzliHT s0+iZjkbO95ICtCdy3okbg+UDyGowWTSwpzDWA3sZxr8 X-Google-Smtp-Source: AGHT+IFUymSlmfUx2YRUyblAT6dvw2RWxiCN3uN1aUoYB5+MKTT+5Z8rIxUmPZn0HCxeDv7FqRPOK5a4f1bD7JA8P+8= X-Received: by 2002:a2e:3215:0:b0:2cd:5a63:81c0 with SMTP id y21-20020a2e3215000000b002cd5a6381c0mr1943093ljy.17.1705259224217; Sun, 14 Jan 2024 11:07:04 -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 16:06:50 -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: 4TClBg5tZpz4nwb 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 15:23, Alan Somers 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. --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/