From nobody Sun Jan 14 00:50:58 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 4TCGt961Ccz56Zdr for ; Sun, 14 Jan 2024 00:51:13 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 4TCGt94J7bz4p4y; Sun, 14 Jan 2024 00:51:13 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2cc9fa5e8e1so89673141fa.3; Sat, 13 Jan 2024 16:51:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705193470; x=1705798270; 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=aViYg8CMnphxOP53XUjbo/7LANtYJfEP/iZBOQnnMJk=; b=ZAS8jAzcjZsqxvM70c5wvWCKDhZK+VUbdWtVwMdV/J5E0J2q2AXEB088OawQVX6F7G lB3xrhjJVe30uo1RQI0FTX5eSqSN9l2Q4frF3A6HVfysxilz5u9zhrOVPLl9GYOdawdU uRMGz79cWs9TOzRhDxFvUPMXPrYkLrhNqms5tUf2PfNzk1Z7zsBSnPxWJL/O8RoXtAY+ OwCZWjlvDXBis72jmOZhFiCTLOMWlxtZz8XAF/zO657vz1wjDtRnvmTNx9l7PQVfPfgx axT30QZIT/b7apkC0JsuhSzU616tn7ySJFt4c3hAgmUQG8YWD2CNEkrsE2szZeVBY3fn C+Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705193470; x=1705798270; 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=aViYg8CMnphxOP53XUjbo/7LANtYJfEP/iZBOQnnMJk=; b=c/Ay+RhBeMOIk5SUJpVxoG4E7OiqRVnwGl2ez6BCY+/JMvIZjyji87p0pcEkIUVGVB JTDc+gzdeFUhV7CZdGloFsGXUK70pshiR1ZWtV3T1OhaxWgiT1Cyf74PlRoeOWgBNP3J dyfl0uGyRwcJuqeqeJOixIhq6wD6Kwv3rxV4TQui8f/FQm0Lw6LZzh3RGmmPcpMn3lo6 7pTcbE8mlXdXQbqP3L6s2VzlEw0eiajjogPis2KdKOxIhi2EFXE5sTqz8Wj1onNRU37G IiJFrWRNIsH56j0jFxnY441KN9APiYZ75LOiM0so7KwVtNLyukZydG8oLKdQQL8YfuCV W7ng== X-Gm-Message-State: AOJu0YwilF6yjNRz7DEU74V0IFcxm6qvjSjHALGxsc1sLhmz8aTf2ePy n1YP2jS9sv3kHEJgcGiACIMwLACirJcN0jswhCA= X-Google-Smtp-Source: AGHT+IHTZkCGjWeQEUotDWICc57tSDNMiDQx5P7YWPTz3nNMI8ubkWGNoYBvcC89NPsSb+6YCPr/dzFCnwZUO6EYqz0= X-Received: by 2002:a2e:9792:0:b0:2cd:143a:ae5c with SMTP id y18-20020a2e9792000000b002cd143aae5cmr1549288lji.51.1705193470508; Sat, 13 Jan 2024 16:51:10 -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: Sat, 13 Jan 2024 21:50:58 -0300 Message-ID: Subject: Re: aio_read2() and aio_write2() To: Konstantin Belousov Cc: Alan Somers , freebsd-threads@freebsd.org, Konstantin Belousov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TCGt94J7bz4p4y 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 s=C3=A1b., 13 de jan. de 2024 =C3=A0s 21:35, Konstantin Belousov escreveu: > In principle the function of the new flag could be done like > aio.aio_offset =3D lseek(fd, 0, SEEK_CUR); > aio_read(&aio); > with the dis-advantage of requiring two syscalls instead of one. There are more disadvantages besides the extra syscall. I've built a green threading framework for Lua on top of Boost.Asio. However I also added support for sandboxed actors (capsicum and jails on FreeBSD). For file descriptors received through SCM_RIGHTS from sandboxed processes, I really don't want to risk blocking the thread (DoS) going through O_NONBLOCK (file IO is always ready, and that's why AIO exists). So, for these file descriptors (one can never know their "type"... whether they refer to pipes and O_NONBLOCK is enough, or they refer to files and AIO should be used), I'll use AIO as well. On Linux I can get away by just using io_uring for everything. Anyway, that's *another* use case. Other applications built on top of Boost.Asio have their own reasoning for choosing between the streaming/random_access interfaces. And they already work on Linux and Windows. --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/