From nobody Wed Jan 10 02:34:32 2024 X-Original-To: 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 4T8sMD3cjjz57JWB for ; Wed, 10 Jan 2024 02:34:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8sMD0Q6Kz4q13 for ; Wed, 10 Jan 2024 02:34:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704854072; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j1KLcBE70pt64GyMqILKRWyrP+RAxJbpXtvEuO0XKZY=; b=wrD9SPI5EW/42pedxM0LCet578LtGke9/VjHHL44ZzvHUBj1MI6zSSD/CxHCaZsd4c8utB fUe+fBYI9fivLkV8+8WRzhPkvQlKuwPivoByVLgdXEUpApZaCqdVBQ3cmMrPMgDIwitrDa f8Mba1s3RxgdlykkWbH7yqlKTb2R6iRxmWV+c2GtsKH2JSW0sWXblgzx+dFdKIX/OlmUXo I7t0vNCIq+D0O+g+kUqmn8oMRBzHidjTQ1nIk4Acxwiy6NBScupV7D4CPIS3YdV/0Id2R+ 6XXjIVXdKt1JEdHU5ra6Bnh4FrGnquYR/8yqrkHahZI/Ugr4TGFd+S5WllBJHQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704854072; a=rsa-sha256; cv=none; b=Pht6pyk0Q0xCOwJEP6KG2Fshc9WgrYgHaFr0avkbu1QXim1ijF53Gb+cyGlvpisPx7Aksm 2/qVqMzgLBt99S7quYLBSKB1Px6Am/xz7vRm3uAmHPcuKzGhhT1Y18RBUjxT6U02KC8VKA p4UoP3U9UslZUkr1JE6eXeFrejHz+3ILQYfgDlVK6en7sL0neGeIn6DTNSgHP823k1QHBo dBnxWThWJY0Tq+UAtNxQdG9LcsaqvwWmRnyA1efoIcZv+9p8YFBuDcVAAQYdjsW3iL5rmA MKl7yKdEY6nbr4EjlHLgpK19n8zOMMBPVYuIcIAvPAEDGtih61bIQTv8vlfHqw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T8sMC6cnNzGXF for ; Wed, 10 Jan 2024 02:34:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40A2YVle058016 for ; Wed, 10 Jan 2024 02:34:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40A2YVOL058012 for threads@FreeBSD.org; Wed, 10 Jan 2024 02:34:31 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 210098] Refine slightly search of highest priority thread on the queue(sleepq_signal). Date: Wed, 10 Jan 2024 02:34:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210098 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Status|New |Closed --- Comment #2 from Mark Linimon --- ^Triage: apparently fixed some time ago. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Jan 12 16:41:23 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 4TBS3l3x8Hz578H1 for ; Fri, 12 Jan 2024 16:41:39 +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 4TBS3k5DTnz4Wdb for ; Fri, 12 Jan 2024 16:41:38 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=mvE+6Ei0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vini.ipsmaker@gmail.com designates 2a00:1450:4864:20::235 as permitted sender) smtp.mailfrom=vini.ipsmaker@gmail.com Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2cd81b09e83so29190321fa.2 for ; Fri, 12 Jan 2024 08:41:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705077696; x=1705682496; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MIpzcdGQntw6wRooErGkIe7sjWDi1TE4kIq35LeOTbA=; b=mvE+6Ei0m5MyUaLViceRg6TuftLXnGB3OSgKOGRthXPUwibn1Q77Z9w3mva+m+o4fd X8ygyv0UgPgGodQbh73GUmuVlDt+nHgdfZTDqEZfK5A4CVluRPtBfpOyeEKWQJvEoL2v aGokZhsAE0Q5VDfQ71vwAC0hsJYdYfAEJL4/TmzXfe26yzc5cs+sE3a4QLEnrzp4JqWT 4rcJM4ZMqfGZBoQFrh+g1XIbc7STTp6CGazrio4eLYW91lA6BD9ISpRQYqGtaABbcbXo z46REK76OUdsoVSJhkw+C8qppKXfifuiyLz9X3WAsco3lUk+GgupHYUluqHf1isTInxa HwBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705077696; x=1705682496; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MIpzcdGQntw6wRooErGkIe7sjWDi1TE4kIq35LeOTbA=; b=quRRl6I3O7geOWYA1DIfBeYD6qwQxUfF/QFMjgAxnml76YNF/lcZlZF25GNf2tFY8f zeP4Mu3NIFPH0yEgu1L78kbNzH0Of2hPriaiE3pav6RxOw/o13+lY3AwFqbj6ggCUXR+ 5RUiH2zDI98aD8ioicM2oeqtvqQKATLsWHhpY4gya2+KsbR0iGjYQHReqBs868hOUxWz pr1ouYiTlKfuWdPZu2VPWAAnlCBLrqpcDnDQpKjfeWF5GJVDVcB0ogDVDI+JpCHOuGIO uzHFuAjDNKagjh1UfU6oOyGMvw7jzwKgP3A3kJ21NiSZEzNFbR7UyOI8fFUbDlgN8xM0 Oylg== X-Gm-Message-State: AOJu0YyQ2Gi04XV0mFZhE0nGnFX6BdU0P71u2vwIkbFCwbv6BD7jALg9 9UWwZxIC9O9PCxwfSABhUCTNnylZR46sX2b+emlCwvdiWlQ= X-Google-Smtp-Source: AGHT+IEk8cKn9cYRbdXh7460DYpLtpV/Tzd7pN+ZoseryW44VSJBONN7RgPkH6ALincOyWdqDsx6dVzurRtpT0wWz64= X-Received: by 2002:a05:651c:2051:b0:2cc:8bc7:570f with SMTP id t17-20020a05651c205100b002cc8bc7570fmr363583ljo.193.1705077696180; Fri, 12 Jan 2024 08:41:36 -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 From: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= Date: Fri, 12 Jan 2024 13:41:23 -0300 Message-ID: Subject: aio_read2() and aio_write2() To: freebsd-threads@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.37 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.996]; R_MIXED_CHARSET(0.63)[subject]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-threads@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-threads@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::235:from] X-Rspamd-Queue-Id: 4TBS3k5DTnz4Wdb Can we have some aio_read() function that ignores aio_offset (i.e. the current file position is used)? I'm trying to port libboost's ASIO file support to FreeBSD, and I stumbled upon this limitation. Boost.Asio only exposes file support for proactor systems (Windows IOCP and Linux io_uring). For Windows and Linux, it's possible to perform the feature I'm requesting (on Linux you just pass -1 as the offset to ignore it in io_uring). Boost.Asio offers two interfaces for file IO on proactor systems: serial access (current file offset is used) and random access (you always specify an offset). Right now it's only possible to implement the random access interface for FreeBSD. What I'd like to see: int aio_read2(struct aiocb *iocb, unsigned flags); int aio_write2(struct aiocb *iocb, unsigned flags); aio_read(iocb) would be equivalent to aio_read2(iocb, 0) and aio_write(iocb) would be equivalent to aio_write2(iocb, 0). Then we would define the following flags: AIO_USEIOV AIO_IGNOREOFFSET aio_readv(iocb) would be equivalent to aio_read2(iocb, AIO_USEIOV) and aio_writev(iocb) would be equivalent to aio_write2(iocb, AIO_USEIOV). The flag AIO_IGNOREOFFSET would instruct the call to ignore aio_offset in aiocb and use the file position (lseek) if applicable. This flag should not conflict with LIO opcodes so one could OR it into aio_lio_opcode for usage with lio_listio() as well. --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/ From nobody Fri Jan 12 17:36:53 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 4TBTHl6hkcz57DbC for ; Fri, 12 Jan 2024 17:37:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBTHk592Zz4gg2 for ; Fri, 12 Jan 2024 17:37:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 40CHasAn057502; Fri, 12 Jan 2024 19:36:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 40CHasAn057502 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 40CHarmQ057501; Fri, 12 Jan 2024 19:36:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Jan 2024 19:36:53 +0200 From: Konstantin Belousov To: =?utf-8?B?Vmluw61jaXVz?= dos Santos Oliveira Cc: freebsd-threads@freebsd.org Subject: Re: aio_read2() and aio_write2() Message-ID: References: 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; R_SPF_SOFTFAIL(0.00)[~all]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-threads@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4TBTHk592Zz4gg2 On Fri, Jan 12, 2024 at 01:41:23PM -0300, Vinícius dos Santos Oliveira wrote: > Can we have some aio_read() function that ignores aio_offset (i.e. the > current file position is used)? I'm trying to port libboost's ASIO > file support to FreeBSD, and I stumbled upon this limitation. > > Boost.Asio only exposes file support for proactor systems (Windows > IOCP and Linux io_uring). For Windows and Linux, it's possible to > perform the feature I'm requesting (on Linux you just pass -1 as the > offset to ignore it in io_uring). > > Boost.Asio offers two interfaces for file IO on proactor systems: > serial access (current file offset is used) and random access (you > always specify an offset). Right now it's only possible to implement > the random access interface for FreeBSD. > > What I'd like to see: > > int aio_read2(struct aiocb *iocb, unsigned flags); > int aio_write2(struct aiocb *iocb, unsigned flags); > > aio_read(iocb) would be equivalent to aio_read2(iocb, 0) and > aio_write(iocb) would be equivalent to aio_write2(iocb, 0). > > Then we would define the following flags: > > AIO_USEIOV > AIO_IGNOREOFFSET > > aio_readv(iocb) would be equivalent to aio_read2(iocb, AIO_USEIOV) and > aio_writev(iocb) would be equivalent to aio_write2(iocb, AIO_USEIOV). > > The flag AIO_IGNOREOFFSET would instruct the call to ignore aio_offset > in aiocb and use the file position (lseek) if applicable. This flag > should not conflict with LIO opcodes so one could OR it into > aio_lio_opcode for usage with lio_listio() as well. Do you need a new syscall for this? We have spares in sutrct aiocb, and can add flags there. From nobody Fri Jan 12 17:44:11 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 4TBTSD2B82z57F5w for ; Fri, 12 Jan 2024 17:44:28 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 4TBTSD0Mr4z4hnC for ; Fri, 12 Jan 2024 17:44:28 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2cd8b64a52dso21489171fa.2 for ; Fri, 12 Jan 2024 09:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705081465; x=1705686265; 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=7MXTqlw59zop+40475NLl3pF4MiP8VWYxlzas8vsAL4=; b=i1bYdIsvuGtBx5cRifftA8MQk+a0lTlHsuNQt0bkLIjrywPiJeilP4PR9d+Ud6XfXU wKFKGI8Nk4DFEeUOMwjvx0UvnnWbqxUYge2PMau+xPz0ieXPFs2ONfeAZ3MhgfrCxaSy DkuVMyTr4cQFaCRB6Xz7LJeQQ7aUK9LiSyBi2z0Juh5u39tdLTJvmhGEOnFbdJq2+yDN 93MocbsHhAPT2F5yws0yqUK5rxRYX5aI95FOxlKxbqmX4NFJeldMNm3L2zqrI6+6P7MA Mh6myrzds7WnMWQ+ffxWtLeuJk0ytzKSbDwRUaBcDgFs3EUxNHNglljPxjxXqsgvJDYA rxog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705081465; x=1705686265; 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=7MXTqlw59zop+40475NLl3pF4MiP8VWYxlzas8vsAL4=; b=ufH5IOGdvThnOHB41MfljnEcR16v169EzKjsOjhIPtCk43+Z9OpxMI36d1Z3N/SMSE 1d8uBhO+hz5+BeLqaCBHLn/YSolCWOmFV5Bjc5CafWd1QPiB3BNmCmS8YmLTC6zEzWan 2oNv0tAI4nNx7+QyS8Y2wrmf1d7nAnpSI6hD7GLL5yrNEbWyAOAVyGSaSAgKUswYC7wa /2wFdXD68zEJ8AoYQPdCZuDD7s2yScxo090vJOrwFIqFp61NtJOdEp5L1f44PXN731Fb wGIJ0/K1LgHZYepHHmjWIKmfUuSp6odw8EujwUYbMF4kuX6BJdAKIg54JYYgDOfqy3L+ CfLA== X-Gm-Message-State: AOJu0YzX+rUti6dVp+hfP8QCzsyftq3vQP46aFVdwJxlFSMR3oDVCnPL WQpIHpQbOnfrIwzaTB4+S+bo/qKOMdkjtyWT5vw= X-Google-Smtp-Source: AGHT+IH3TSlhBxT5Qh6dHmMFdM5WioGRl6euwL8GR3s40Rc5QR4s+VWSTO+lPd56qXmPH5u0HjyIzDcyNCrFiBFen3g= X-Received: by 2002:a05:651c:1247:b0:2cd:6221:b65a with SMTP id h7-20020a05651c124700b002cd6221b65amr853383ljh.25.1705081464866; Fri, 12 Jan 2024 09:44:24 -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: Fri, 12 Jan 2024 14:44:11 -0300 Message-ID: Subject: Re: aio_read2() and aio_write2() To: Konstantin Belousov Cc: freebsd-threads@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TBTSD0Mr4z4hnC 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)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] Em sex., 12 de jan. de 2024 =C3=A0s 14:37, Konstantin Belousov escreveu: > Do you need a new syscall for this? Not really. As long as there's a way to opt-in for ignoring the member aiocb->aio_offset, it works for me. --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/ From nobody Sat Jan 13 19:50:47 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 4TC8Cn0Mvtz56X36 for ; Sat, 13 Jan 2024 19:51:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC8Cm19nNz4CyS for ; Sat, 13 Jan 2024 19:51:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 40DJoln3051695; Sat, 13 Jan 2024 21:50:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 40DJoln3051695 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 40DJoluZ051694; Sat, 13 Jan 2024 21:50:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Jan 2024 21:50:47 +0200 From: Konstantin Belousov To: =?utf-8?B?Vmluw61jaXVz?= dos Santos Oliveira Cc: freebsd-threads@freebsd.org Subject: Re: aio_read2() and aio_write2() Message-ID: References: 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; R_SPF_SOFTFAIL(0.00)[~all]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-threads@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4TC8Cm19nNz4CyS On Fri, Jan 12, 2024 at 02:44:11PM -0300, Vinícius dos Santos Oliveira wrote: > Em sex., 12 de jan. de 2024 às 14:37, Konstantin Belousov > escreveu: > > Do you need a new syscall for this? > > Not really. As long as there's a way to opt-in for ignoring the member > aiocb->aio_offset, it works for me. Please see https://reviews.freebsd.org/D43448; not tested. Effectively I added the new ops to lio_listio(2) instead. From nobody Sat Jan 13 22:18:41 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 4TCCVS1Wp0z56p0t for ; Sat, 13 Jan 2024 22:18:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) (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 4TCCVR3K5fz4XF7; Sat, 13 Jan 2024 22:18:55 +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.49 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-7cdb67ec4caso2102768241.2; Sat, 13 Jan 2024 14:18:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705184333; x=1705789133; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UpNkYTuvN41Z94QLLLtb7Vl7Fs5QU3JgsQbv7LsFqVM=; b=URBz0bOCXOERkl2ErxkZ50YxVH+iSAFsS5Ws4J3R71PsWD9hwZq7wInzkIVyHfwvI1 DDyjqUariSfvL6GPQe8GQsrt25xCgqTyom5wlUzBF0kU8GE+b4Q8Z02gorvNA3pzIZIl Wjlpop1cznH5w/xo+j6BHY/rAf0gM5SKuQInnUbft62Uu/ZgGEwv0hEZfa0FGTx41AVw yDk8/3njQD3/y2YKPjQ72+bar396FeYK1BhXW03trRAP3pputBmIr2M3J43lVKe3nD9+ SHU3Pa98JpHCbTzqadLx37uHo7bMPVqnPPVv4yq/2KyC7SzzMR4YXHxrQukjPxeKVzWN xT6w== X-Gm-Message-State: AOJu0Yy+mt12CdRat8sfFQ32uWK259uQSZJBSFqPUd8knvZPymqFMZU4 BuY+sYOdBblRlKVyXXyWZ63mE+zathYAT+mfVy00tGN3dyA= X-Google-Smtp-Source: AGHT+IF7RL6oTUawLXmskp8rI87/f9u6GHaUsZ9eU/H1r7E3c6NIGa/z5SJc/wY1STjaVpyjBdEWnDWFLWUKuYBr3Yo= X-Received: by 2002:a05:6102:34d6:b0:467:ff0a:a7ff with SMTP id a22-20020a05610234d600b00467ff0aa7ffmr3036349vst.19.1705184332956; Sat, 13 Jan 2024 14:18:52 -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 From: Alan Somers Date: Sat, 13 Jan 2024 15:18:41 -0700 Message-ID: Subject: aio_read2() and aio_write2() To: freebsd-threads@freebsd.org, Konstantin Belousov , =?UTF-8?Q?Vin=C3=ADcius=5Fdos=5FSantos=5FOliveira?= Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.85 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; NEURAL_HAM_LONG(-0.96)[-0.964]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCPT_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; 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]; FREEFALL_USER(0.00)[asomers]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.49:from]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.49:from] X-Rspamd-Queue-Id: 4TCCVR3K5fz4XF7 I'm not on this mailing list, but I saw kib's code review and I have some comments > Can we have some aio_read() function that ignores aio_offset (i.e. the current file position is used)? I'm trying to port libboost's ASIO file support to FreeBSD, and I stumbled upon this limitation. The fundamental problem with using the file's seek offset with AIO is that multiple operations may be in-flight at any one time that depend on the seek offset, and there's nothing that enforces their ordering. Whether you use aio_read2 as you suggested, or lio_listio as kib suggested, as soon as you submit a second operation before the first one completes the results become undefined. That's why no existing AIO operations involve the seek pointer in any way. How does boost.asio address this problem? Are its operations completed in a strict sequence? -Alan From nobody Sat Jan 13 23:03:30 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 4TCDVC5K1Lz56t5w for ; Sat, 13 Jan 2024 23:03:47 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 4TCDVC0j0Qz4bVC for ; Sat, 13 Jan 2024 23:03:47 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2cd853c159eso35787741fa.2 for ; Sat, 13 Jan 2024 15:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705187024; x=1705791824; 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=K2mhsOO3y7iPiFElPf3FYhkD3P64D2aCDFezc37SjBg=; b=Eu2kl1TQ/YomcXbwLq3PCEZX2Ro4lycn8RZdhBhbvZSfDol1rPnUNgkkvoT8rEgyb8 vch9Qbdt1TDPvk35ruGS0FjtmFiTt/ZkUhu3A+8IypwBWDpCx6oyATLepfUnQG9DTqdf D4kGrJts30JdhM6LD3Jos6qZlQZ8yGGG0LKYLW4JppmLiKrHyU5Z4x8RBrEuX+3ndhqP hba+8PKFiI8CfISuA7ZCqYFCId5t0EJLh8LXRjhcm4FzpcCh9EbeQr9WGBlanux9yjzi ru+Sd6WdYf0BG5hiNtJdo3NH7bi8jIQeIfEQSn3vXSgXjBKCp+OBuXsjFoxrENcHoDz7 scEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705187024; x=1705791824; 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=K2mhsOO3y7iPiFElPf3FYhkD3P64D2aCDFezc37SjBg=; b=Hn1ZnuaeV1SSphSnhI669oIoKFe94higflu+CyI40vZC0C64YF8CVLGiModBEd8HIU by6eIeT37YAP0P63COc4KOxXAexEcglIiTFfEI2CehrOR9gb1d9J9kNho1RCtAoxRn1Y /GRlrZOkq8o9NjYoCWiOHHQAD1IjLz609xOcUu3sGPt9QW/AQswCljOYDz4Yx6NsUwSo DhegdKcRVpJqnTfYZzl9asFVHP92OZpTB7iBXNLC9RHa2yTA80aBQUDscjarPKfP5Lcx xUe3nsdWin9JV2io95ibaWdaCzaJtQtB9BsacF5QvyX6FPGrQ2qrrp23N9Ao2iS45ivH Q2xw== X-Gm-Message-State: AOJu0Yzi7HzlVK3MW0eY/OXKho5YtskqSyuKePGeqghZcAzBKM+nHSCT jaYaMkrKio04pl+Z30DE6itRS7q6lDdPYKSP4Bg= X-Google-Smtp-Source: AGHT+IGAlfCSt5QZg9oSPXXHcNzNAXZhrYeEYfOlXb2Ab0Y9B9vEZoLX9MUttBXBUZeBpZlIqAXtmmb0eh4DjrFsRYI= X-Received: by 2002:a2e:9557:0:b0:2cd:696e:a748 with SMTP id t23-20020a2e9557000000b002cd696ea748mr1616706ljh.54.1705187023838; Sat, 13 Jan 2024 15:03:43 -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 20:03:30 -0300 Message-ID: Subject: Re: aio_read2() and aio_write2() To: Konstantin Belousov Cc: freebsd-threads@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TCDVC0j0Qz4bVC 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 16:51, Konstantin Belousov escreveu: > Please see https://reviews.freebsd.org/D43448; not tested. > Effectively I added the new ops to lio_listio(2) instead. It looks right to me. However the flag is confusing. I'd suggest using LIO_FNOFFSET instead as it means the opposite of FOF_OFFSET. --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/ From nobody Sat Jan 13 23:28:06 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 4TCF2R3DTrz56wSb for ; Sat, 13 Jan 2024 23:28:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCF2Q110jz4ffg for ; Sat, 13 Jan 2024 23:28:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 40DNS60c005127; Sun, 14 Jan 2024 01:28:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 40DNS60c005127 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 40DNS6MK005126; Sun, 14 Jan 2024 01:28:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 14 Jan 2024 01:28:06 +0200 From: Konstantin Belousov To: =?utf-8?B?Vmluw61jaXVz?= dos Santos Oliveira Cc: freebsd-threads@freebsd.org Subject: Re: aio_read2() and aio_write2() Message-ID: References: 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; R_SPF_SOFTFAIL(0.00)[~all]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-threads@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4TCF2Q110jz4ffg On Sat, Jan 13, 2024 at 08:03:30PM -0300, Vinícius dos Santos Oliveira wrote: > Em sáb., 13 de jan. de 2024 às 16:51, Konstantin Belousov > escreveu: > > Please see https://reviews.freebsd.org/D43448; not tested. > > Effectively I added the new ops to lio_listio(2) instead. > > It looks right to me. However the flag is confusing. I'd suggest using > LIO_FNOFFSET instead as it means the opposite of FOF_OFFSET. Well, LIO_FOFFSET means using the file offset, so the name is logical. FOF_OFFSET is internal kernel flag, not exposed to userspace. From nobody Sat Jan 13 23:46:06 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 4TCFRL3tqqz56yFp for ; Sat, 13 Jan 2024 23:46:22 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 4TCFRK6LQzz4hBn; Sat, 13 Jan 2024 23:46:21 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2ccbc328744so92166411fa.3; Sat, 13 Jan 2024 15:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705189579; x=1705794379; 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=qE8LP1JVM0VfI7tKTZzfYzGaJa/x3ymG1HjyiuTkx00=; b=cjb/rBEKwU4dh8bQMsMT20SCrHYksP6roA5GTU588mRpbEgmjzPYuH6sR1tNdeAPnQ o2vA0ZwoCyOBcXsk8E8k3BkN/4lRi7e8he3GN0qtknyCpg62Yv/TKCjDYGuvZPASnYcQ MBmwUSA7CBmQ7UvRL3RBjSGijbgCypMV2o+O6vjWh/YkP1gGLDn2pJM3E5cpbKkbb96i vZBqPw+EY05D80eL0MPkfozCDJoFdG1xGUksvedes+C3kq01tM+bOX01qB8z5t1y+DU6 iXiRqjcKh+2KwBP56bS7V/xZ9q5RU9dkF1bl35ntaL0TAd572QQzICEvjkSzLALdR2hW eLEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705189579; x=1705794379; 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=qE8LP1JVM0VfI7tKTZzfYzGaJa/x3ymG1HjyiuTkx00=; b=oolI4gnZsXaLImYh62/HXpE4qgnFEKjssjaXZEZTNmtFkOQjfX2gkgTYEHLeLZk22q Wy0UCklImpc5/XjQ5obWbQzCqYrNCWT2OF1x0hIAdNOKlJyjedlz4tReTrHPgrOOEBcU 3EXVR6tSDeynq5ZTyeJHAORTACEsmejDJ8loViTvjrYVgZUg/kyhwhiFaWnSb0CxvvyR 2JOZMOtJoo2VEEb3zEpcaxd/rHTl3LEbx/lXiqnGgJoTABEuSYxIh617moRYT5SB2HwL ihoGI5aBL92vybg6oTT6lWMIXaYkTI3drHgvN3uUMeBG2wjX0lEnXAshQUDjgP0ZvNjL esdg== X-Gm-Message-State: AOJu0YzQoX0zR/ucol4RWnKhTKOTVsTFcWNV1fOWAJbDyW0evmV2aTNZ 00a+zFoLiEfNdhkq/XCM1prjbLUgDGzy424ijDrtW4rzvtY= X-Google-Smtp-Source: AGHT+IHUZldjbxo4QZyQpJZuVQJyb6K8mYoHSvJvVunZgAI2qgsxByjI8i6fxoBDPAN/mXyWqbEbSzpuDb9kpaip/xI= X-Received: by 2002:a2e:390a:0:b0:2cc:ea0d:f6c0 with SMTP id g10-20020a2e390a000000b002ccea0df6c0mr1598889lja.83.1705189579019; Sat, 13 Jan 2024 15:46:19 -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 20:46:06 -0300 Message-ID: Subject: Re: aio_read2() and aio_write2() To: Alan Somers Cc: freebsd-threads@freebsd.org, Konstantin Belousov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TCFRK6LQzz4hBn 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 19:18, Alan Somers escreveu: > I'm not on this mailing list, but I saw kib's code review and I have > some comments > > > Can we have some aio_read() function that ignores aio_offset (i.e. the = current file position is used)? I'm trying to port libboost's ASIO file sup= port to FreeBSD, and I stumbled upon this limitation. > > The fundamental problem with using the file's seek offset with AIO is > that multiple operations may be in-flight at any one time that depend > on the seek offset, and there's nothing that enforces their ordering. That's not different from creating two threads and calling read() from both threads in parallel. The kernel can do nothing to prevent bugs in userspace applications. It's already possible to violate ordering using threads. > How does boost.asio address this problem? You don't address this problem. Applications doing this are buggy. io_uring in Linux doesn't address this problem. IOCP in Windows does give a few guarantees, but for now I'd argue against it. Applications shouldn't start a second stream operation when the last one hasn't even finished yet. > Are its operations completed in a strict sequence? When the kernel dispatches completion events (SIGEV_KEVENT/EVFILT_AIO) to the process, Boost.Asio will route them to the correct module within the program (the one that started the associated operation). The program can retain ordering by only scheduling new operations when the last one finished. Boost.Asio by itself will act just as a portable layer between the program and the OS. Boost.Asio won't by itself give any sequencing guarantee. Ordering problems can happen even if you only use kqueue with a single thread. Here's an example from the real-world: https://sourceforge.net/p/asio/mailman/asio-users/thread/5357B16C.6070508%4= 0mail1.stofanet.dk/ (keep reading past the multi-threading problems) Here's a condensed explanation for what happened in the example: https://docs.emilua.org/api/0.6/tutorial/streams.html#composed-operations --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/ From nobody Sat Jan 13 23:48:08 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 4TCFTf6b8fz56yS6 for ; Sat, 13 Jan 2024 23:48:22 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 4TCFTf5xgzz4gt3 for ; Sat, 13 Jan 2024 23:48:22 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2cd8bd6ce1bso31354971fa.1 for ; Sat, 13 Jan 2024 15:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705189701; x=1705794501; 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=83d6nO2kweFh0sJPGnvPQBXBm0H9n68rhdssrj9siNg=; b=WvSsszsLW43b3KC9EoGfOI7B/DTjvAMT3S+KFyul4KpQW6wLwDNgmmIg8GrRFNZyrg 4vzJLTYYwyTlnCqIWzbB2Rm8JXHyPuSMKeYUrpzCuNdq0T6ESauuuLz8B7leo01bUUPX FQ9sR/Sp3nMs+zMznKO/Q0O1StsRVk5gpwTy2LJVUIpTTb8Gkr93l4GK0iDbor+KlUwk /YPY9E4uvp8eV/hJCbyNAz7GchNtoHcnEIN8CawBs+ati2aWXEpiebxK4F8iIPC1WNv1 jiZIOtLdGhTRUE7m6Mvst7x8afBqzW0+vwwwJKGnnIUPlTHruIGD2mlpqWP20zFUT97S /cWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705189701; x=1705794501; 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=83d6nO2kweFh0sJPGnvPQBXBm0H9n68rhdssrj9siNg=; b=eEOjaheISiGK/xOFROqNCHg7cH43LtHAKPh7AQk2UI0MTFvtSMOEky/iwviAzuRycQ c/jgrM7Zoebti9lfsqJw6itzVrE3F2+/jGYrQ+aD4P7atTV0ntbOjSliga0I4bB/Au6e P0l1NZyT3PolADsn3vDzBSwCU26f9jL+KSkH7h1DZDSjpBA44Pt1yEPvIoB86gRua5jM Ig/l+/lHz5duXaJmU+cLFwxmKQ+MS5X6DfRXMUepJWWKUrptseA1Pg5GJ4wQqlNoZCWY caKr2RNLvQc9onKkRdp+U54mz948QbHqvH62AZwRm3nIM1qyGYn1VukezlCknetMuhlg Ra0w== X-Gm-Message-State: AOJu0YzHRdfTgb0q0dPnSQLat3tQV523Se9Ei7AGPiG542TKVyGvCqsE 8Qk5OL4FB2Z2x8HhZkVdp5uUruIDDBgRMjnnQKvvufTp X-Google-Smtp-Source: AGHT+IFBMnheaO38T0BEXnMKdE3cDxlJuXCZPnnNcCyJvK8kcaOrvuaNX31AnRCLRtHZXtyY5cSYAPUoPXCC/2MGoAs= X-Received: by 2002:a2e:b803:0:b0:2cd:7e88:33c6 with SMTP id u3-20020a2eb803000000b002cd7e8833c6mr924177ljo.61.1705189701216; Sat, 13 Jan 2024 15:48:21 -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 20:48:08 -0300 Message-ID: Subject: Re: aio_read2() and aio_write2() To: Konstantin Belousov Cc: freebsd-threads@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TCFTf5xgzz4gt3 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 20:28, Konstantin Belousov escreveu: > Well, LIO_FOFFSET means using the file offset, so the name is logical. > FOF_OFFSET is internal kernel flag, not exposed to userspace. It works for me. --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/ From nobody Sun Jan 14 00:23:43 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 4TCGGh3pYDz572Qv for ; Sun, 14 Jan 2024 00:23:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) (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 4TCGGg6CsGz4lZ1; Sun, 14 Jan 2024 00:23:55 +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.219.45 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-67f7bd86cafso49367296d6.0; Sat, 13 Jan 2024 16:23:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705191835; x=1705796635; 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=o/rL1813/OlakPo7+QOR4nmAWL3KG78SbQQo12xe2wI=; b=Me/8xwN33nk0WrbOF9IPeLfjt1P8PV3CAU7pw+JhPu77S+9JvTIxozqVRtsaLXnevq e4qu0nygIUT6G2lAlaZY7/tTt6PxzkvGNs5vdkW5THqkkNILzMr7Sl10Iw5x+13cTJA5 5o2nAFk9kPly0XBLO+BmqxDOjbJce0togV1S8ti3i8buFiNnY6azIVJk9CWutgWyZ+hj mNfSfgLHthg+u+EOmY/iAsfMqnfMI57qKhwuEmroeMl5sAYx2R1CYTIQYlUMQdjABN8T sHPNeymOwGKOZF9kNHH2HmMUTK95yYwcgELG1snUpmbuPWr91hL50kkFgTFtukigVw/t gvSA== X-Gm-Message-State: AOJu0YxWQAm6RtO51rkyDPTFwPUuXbFNEBfFh4yi/5UZCoBNup37hd7d yJQ8GrEr4r4nPfv67qBn+IqUsmwtvK/KuSyx7CbV3IUB X-Google-Smtp-Source: AGHT+IFJeYboaA46R7BpS38bwucSpl2WAklhBAsyDcdZpWma2iWlMvE3jJI7ApmiDtLemBUVCVfSuvXRC5ZEkK3vlXU= X-Received: by 2002:a05:6214:dad:b0:680:aedb:72fe with SMTP id h13-20020a0562140dad00b00680aedb72femr4742156qvh.81.1705191835004; Sat, 13 Jan 2024 16:23:55 -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: Sat, 13 Jan 2024 17:23:43 -0700 Message-ID: Subject: Re: aio_read2() and aio_write2() To: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= Cc: 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.89 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; 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]; FREEFALL_USER(0.00)[asomers]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.45:from]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.45:from] X-Rspamd-Queue-Id: 4TCGGg6CsGz4lZ1 On Sat, Jan 13, 2024 at 4:46=E2=80=AFPM Vin=C3=ADcius dos Santos Oliveira wrote: > > Em s=C3=A1b., 13 de jan. de 2024 =C3=A0s 19:18, Alan Somers > escreveu: > > I'm not on this mailing list, but I saw kib's code review and I have > > some comments > > > > > Can we have some aio_read() function that ignores aio_offset (i.e. th= e current file position is used)? I'm trying to port libboost's ASIO file s= upport to FreeBSD, and I stumbled upon this limitation. > > > > The fundamental problem with using the file's seek offset with AIO is > > that multiple operations may be in-flight at any one time that depend > > on the seek offset, and there's nothing that enforces their ordering. > > That's not different from creating two threads and calling read() from > both threads in parallel. The kernel can do nothing to prevent bugs in > userspace applications. It's already possible to violate ordering > using threads. > > > How does boost.asio address this problem? > > You don't address this problem. Applications doing this are buggy. > io_uring in Linux doesn't address this problem. IOCP in Windows does > give a few guarantees, but for now I'd argue against it. > > Applications shouldn't start a second stream operation when the last > one hasn't even finished yet. If you shouldn't start a second stream until the first has finished, the what is the reason for using AIO? This doesn't sound like a good application for AIO to me. > > > Are its operations completed in a strict sequence? > > When the kernel dispatches completion events (SIGEV_KEVENT/EVFILT_AIO) > to the process, Boost.Asio will route them to the correct module > within the program (the one that started the associated operation). > The program can retain ordering by only scheduling new operations when > the last one finished. Boost.Asio by itself will act just as a > portable layer between the program and the OS. Boost.Asio won't by > itself give any sequencing guarantee. > > Ordering problems can happen even if you only use kqueue with a single > thread. Here's an example from the real-world: > https://sourceforge.net/p/asio/mailman/asio-users/thread/5357B16C.6070508= %40mail1.stofanet.dk/ > (keep reading past the multi-threading problems) > > Here's a condensed explanation for what happened in the example: > https://docs.emilua.org/api/0.6/tutorial/streams.html#composed-operations > > -- > Vin=C3=ADcius dos Santos Oliveira > https://vinipsmaker.github.io/ From nobody Sun Jan 14 00:35:30 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 4TCGXB0NCcz573RZ for ; Sun, 14 Jan 2024 00:35:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCGX95pBlz4n0Z; Sun, 14 Jan 2024 00:35:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 40E0ZUaG023212; Sun, 14 Jan 2024 02:35:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 40E0ZUaG023212 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 40E0ZUlu023211; Sun, 14 Jan 2024 02:35:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 14 Jan 2024 02:35:30 +0200 From: Konstantin Belousov To: Alan Somers Cc: =?utf-8?B?Vmluw61jaXVz?= dos Santos Oliveira , freebsd-threads@freebsd.org, Konstantin Belousov Subject: Re: aio_read2() and aio_write2() Message-ID: References: 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED,URIBL_SBL_A autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4TCGX95pBlz4n0Z 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_RCPT(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Sat, Jan 13, 2024 at 05:23:43PM -0700, Alan Somers wrote: > On Sat, Jan 13, 2024 at 4:46 PM Vinícius dos Santos Oliveira > wrote: > > > > Em sáb., 13 de jan. de 2024 às 19:18, Alan Somers > > escreveu: > > > I'm not on this mailing list, but I saw kib's code review and I have > > > some comments > > > > > > > Can we have some aio_read() function that ignores aio_offset (i.e. the current file position is used)? I'm trying to port libboost's ASIO file support to FreeBSD, and I stumbled upon this limitation. > > > > > > The fundamental problem with using the file's seek offset with AIO is > > > that multiple operations may be in-flight at any one time that depend > > > on the seek offset, and there's nothing that enforces their ordering. > > > > That's not different from creating two threads and calling read() from > > both threads in parallel. The kernel can do nothing to prevent bugs in > > userspace applications. It's already possible to violate ordering > > using threads. > > > > > How does boost.asio address this problem? > > > > You don't address this problem. Applications doing this are buggy. > > io_uring in Linux doesn't address this problem. IOCP in Windows does > > give a few guarantees, but for now I'd argue against it. > > > > Applications shouldn't start a second stream operation when the last > > one hasn't even finished yet. > > If you shouldn't start a second stream until the first has finished, > the what is the reason for using AIO? This doesn't sound like a good > application for AIO to me. I suspect that ultimately this feature is for some variant of the green threads (not the word 'reactive' appeared somewhere in the communications). The feature allows to offload the blocking io to different context, leaving the current thread context on CPU. With such scenario, it is clear that 'forwarded' read() operations should be already correctly ordered by the caller. In principle the function of the new flag could be done like aio.aio_offset = lseek(fd, 0, SEEK_CUR); aio_read(&aio); with the dis-advantage of requiring two syscalls instead of one. > > > > > > Are its operations completed in a strict sequence? > > > > When the kernel dispatches completion events (SIGEV_KEVENT/EVFILT_AIO) > > to the process, Boost.Asio will route them to the correct module > > within the program (the one that started the associated operation). > > The program can retain ordering by only scheduling new operations when > > the last one finished. Boost.Asio by itself will act just as a > > portable layer between the program and the OS. Boost.Asio won't by > > itself give any sequencing guarantee. > > > > Ordering problems can happen even if you only use kqueue with a single > > thread. Here's an example from the real-world: > > https://sourceforge.net/p/asio/mailman/asio-users/thread/5357B16C.6070508%40mail1.stofanet.dk/ > > (keep reading past the multi-threading problems) > > > > Here's a condensed explanation for what happened in the example: > > https://docs.emilua.org/api/0.6/tutorial/streams.html#composed-operations > > > > -- > > Vinícius dos Santos Oliveira > > https://vinipsmaker.github.io/ From nobody Sun Jan 14 00:35:51 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 4TCGXl6g5yz573rk for ; Sun, 14 Jan 2024 00:36:07 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 4TCGXl4wPTz4n5c; Sun, 14 Jan 2024 00:36:07 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2cd84600920so40744721fa.1; Sat, 13 Jan 2024 16:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705192564; x=1705797364; 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=4F+mUBlQ0CERU/oXLCJ5tkwj5lLoYYGNW6LeWziMau0=; b=N3a4ihte5F2YBHP1D8xuAxzMSK+0o64X55aGJQFQP0hXUlEmB2p33uE9ijG0bOOUsY /ioWLdec2xDUSP9BYtwbBmFg0+beJ/KyAZTHBwRt9oedIPVlaWMSkL1SLU+3VLMn/gOy 9bI6oQ7MCJ2La1iQHBEBFonVLJULiecwGrxtAqKj/+p6nh7rcGch1QJ+p9ZniOPfJf+4 2ywkho7PrWwRgvDMv8hVpD9S5naqMgbiMvuewCfNHjO36BfEK0b+EFjRwk7jmo470ZFw yBhxcB/SXd20vL8dvKZtQpT9q9VMaNuVsVOETkKA7ZBPxd13SRBBvzHBjXMEGyiYRyCm 8HYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705192564; x=1705797364; 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=4F+mUBlQ0CERU/oXLCJ5tkwj5lLoYYGNW6LeWziMau0=; b=AQWEiJJ1ekiZAw08xEvrCyyJLw4sAxphE8GP9Y8eSVU2Ck9N6XxnSTpmRlpJzrDHLf XxeH759Vuki58/ZAC8pu/oWdVaEDy16Kir5aIEQEm+y8qgjncRD7odNawLeqLOuxJs6E me9i3vpRoYztjgrVvJZuaOBGyzkqEqqE5yMz36f74JAidmpi8QVCY7YS9D9J1YygxHtC Ijnj4OJtd+hAJJwScnCiMmfSYqkmpE9R6vlnxBOc1tg5bBYdoiBYiwYdCTDFI14dckAA uh2uNAbrdoIxvEPrBhZl6KN2ZhkbEkjaWW1YbJE8R08wHiBmko2V5MVUD+5bU6fqwJ0R AuCA== X-Gm-Message-State: AOJu0Yxg6GtpVkTNHcuYyrZUkJNTdRDI0Zd7cCpHdQM8MePyaELtzhOD Jqb+y3yPtffrvr61b7WT7qeVEl4wkr0PZxpjUvlAfay6Kks= X-Google-Smtp-Source: AGHT+IENavSTJc6mjczJ+hRzzqt6eL8mV0HjPqYeVPuYqoNHsjoK5q+1Ehrq2/3Pl4c6cZCCArZY7o3PlL0pZbIGW2k= X-Received: by 2002:a2e:869a:0:b0:2c9:d872:abd3 with SMTP id l26-20020a2e869a000000b002c9d872abd3mr1434019lji.81.1705192564395; Sat, 13 Jan 2024 16:36: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: Sat, 13 Jan 2024 21:35:51 -0300 Message-ID: Subject: Re: aio_read2() and aio_write2() To: Alan Somers Cc: freebsd-threads@freebsd.org, Konstantin Belousov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TCGXl4wPTz4n5c 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:23, Alan Somers escreveu: > If you shouldn't start a second stream until the first has finished, > the what is the reason for using AIO? This doesn't sound like a good > application for AIO to me. You use AIO on different files. AIO doesn't block the thread -- on FreeBSD with AIO daemons -- that initiated the (A)IO operation. The kernel is in the best position to judge how many threads should be used for file IO. It's best to leave this role with the kernel instead of the userspace process. The process remains unblocked to perform other concurrent tasks (e.g. socket IO through kqueue). Furthermore, Boost.Asio won't use AIO *just* for serial IO. Whenever possible, the application can use the random access interface as well (one can even mix both approaches for different files). It works fine on Linux and Windows. I don't see why FreeBSD should be special here. --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/ 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/ From nobody Sun Jan 14 16:30:07 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 4TCgjn6F86z56ZhQ for ; Sun, 14 Jan 2024 16:30:21 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 4TCgjm6WRPz4Gqm; Sun, 14 Jan 2024 16:30:20 +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.160.172 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-42987bc95ffso55648311cf.1; Sun, 14 Jan 2024 08:30:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705249820; x=1705854620; 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=NH1uTUwj65F53Kf2zl5PxXmnPGMW43a73jqqd/UgO34=; b=GCB3Yv+V3oTyAo1ppzGdO4tYx7cLfh+4p+qFcVoEZVvRBdudQL8FV6oiyT9cA0hhEr qPyRzPlwlWkKQxkxLGeX/p/4+XjnLtUljQllxvwm0Z3JCNgQeDoPkBrmsnx7eNOrwa/j 18Jg60mwwC2R1BWG7zmTSoMadwtA7BUs3qi3S/cBUPobyyy7cxQorewdS4UR4KbkqoKq Awp727lqWhZvfiLWp6YNNpE2sHAySj6Kgf6LRkhtc3J+gwkbN46W778bm0Ueg5sqloaZ g0Y3vAj4mL6fVCziAboRSyAShRBQewDFahNQ+DpLadrZjDSTfYc7GQerlisrbG8q0A7X h+Xw== X-Gm-Message-State: AOJu0YxctySqJfF9rZ1ENV16DqipRZdA86pMwtBZ83MA4eOuSEey8932 saNZ1Aq2pHvUusGB3cncRaxoPGUGKeZi3QwyAko= X-Google-Smtp-Source: AGHT+IGqOAggR2qaakOeoj8JzXGNm3bw+ZuRb/9OfeNz1ilusubZGkDHsvdFcJW1Z9+OYfO6WNfaUFsZ4o8TGNNsf30= X-Received: by 2002:a05:622a:1991:b0:429:c8ba:34ea with SMTP id u17-20020a05622a199100b00429c8ba34eamr202763qtc.53.1705249819806; Sun, 14 Jan 2024 08:30:19 -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 09:30:07 -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.87 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.968]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; 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.160.172: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.160.172:from] X-Rspamd-Queue-Id: 4TCgjm6WRPz4Gqm On Sat, Jan 13, 2024 at 5:51=E2=80=AFPM Vin=C3=ADcius dos Santos Oliveira wrote: > > 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. I don't understand. What are you worried about that would block? lseek never does. It never actually goes to disk; it just retrieves a variable from within the kernel. So while the expense of a syscall is non-zero, you don't have to worry about lseek blocking. From nobody Sun Jan 14 17:07:34 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 4TChY52w0pz56gQH for ; Sun, 14 Jan 2024 17:07:53 +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 4TChY50cVHz4SYZ; Sun, 14 Jan 2024 17:07:53 +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-2cd33336b32so104232491fa.0; Sun, 14 Jan 2024 09:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705252068; x=1705856868; 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=L1+XgSQ7GL3/5CTaus0gQwHH5I5ZuOKws/zAG8i0DyA=; b=RoDnz7wFJeUVu+QjylIYNmMtsSOk03MiZ8hrCaKMKaELq1VpPUa9pNJL2OJ57Y/mPB Qe4VcsJ+ZrS4gpA1CZNi7kQqZR3pF8fwxozXKlS6+QaEvjrgQ6xXCQOnOwB4/qZFyN5F mAsC5Z8bM9u4LUzcteErxDJkzpOsVO8ymerGH/D3zs7zj+EgsW2ni+IxoEUgMho80y4c vzNcSdUMgRr7J+gAG78U9DS63ThPyVN7Jcso+EOawIOMw3gV0H4cpEfFCtVtzrnMqcZV EEYMtjjnPFdVMZXA61lcrAKV3pd8fzFsPM27CoUHqm0cJsn8wxis27bcJCErY41T81sf LX9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705252068; x=1705856868; 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=L1+XgSQ7GL3/5CTaus0gQwHH5I5ZuOKws/zAG8i0DyA=; b=Cqt/DVDiRrFtcHI8dk1JSGRmBYIciVD0RqAU42TwYCAmjtxOoxLlT8m8OXOLvAW+9S LgoXloH0yP/sxxlcQLmCkZEUhruKb4TjF2+gP4177EZbleGDsfCNRTdPoCGfDE7ZSAYy xszRxKqcsy4UvbKF8kwhpDIVOz8mRKyCr9w43QAQ+I9AgB533XFOB3xAaBGr8c+rG8st BLUGE1HB05FQsBUqRGUw4UFq3KLgUlfqIVX8u2f4ta7vofd3zdnhryFMrc3m1avJ/zKU 1foilflAP5k/uePLjmrtpM8DL4ZRPWseX2ZwOTosUIR3vhCsUodNhM069muAb9VIcpec UIVg== X-Gm-Message-State: AOJu0YyyhygygAn5iqKHdUy93hPxR34auCRmbqO1sCtIOxZPEXzPuytq 8nEw2PZnJsqUjsu9cAFIqTU36En6dVzfZmUeFLIgtAmAywo= X-Google-Smtp-Source: AGHT+IHrduTqxpuVgZdzGr47/T8TiNiVZa5bT7zRSpRGcYvCez9hCLNul0OWicfnLqegyhamlMP99+JN/hjU6aa3B0c= X-Received: by 2002:a2e:a413:0:b0:2cd:8f26:a1e9 with SMTP id p19-20020a2ea413000000b002cd8f26a1e9mr2082843ljn.37.1705252067435; Sun, 14 Jan 2024 09:07: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: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= Date: Sun, 14 Jan 2024 14:07:34 -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: 4TChY50cVHz4SYZ 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 13:30, Alan Somers escreveu: > I don't understand. What are you worried about that would block? > lseek never does. It never actually goes to disk; it just retrieves a > variable from within the kernel. So while the expense of a syscall is > non-zero, you don't have to worry about lseek blocking. Sorry, that was a lot of condensed information that I dumped together. We can use lseek to get the offset and use AIO specifying the offset we just queried. However the untrusted sandboxed process might actually send as a socket file descriptor (we don't control what we get from the untrusted sandboxed process), and lseek is then inappropriate. From what I've read from the source code, we can pass these bogus offsets to AIO, and it'll just work. However we're still paying an extra syscall (and code doesn't feel right anyway). Anyway, the kernel *already* has this thread pool (AIO daemons), and the only change required here is a flag that controls whether FOF_OFFSET is passed along. That's a pretty non-invasive change. What is the problem? Again, the model already works fine on Windows and Linux. -- Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/ From nobody Sun Jan 14 17:13:43 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 4TChh64GFgz56hg8 for ; Sun, 14 Jan 2024 17:13:58 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (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 4TChh53f3xz4T8d; Sun, 14 Jan 2024 17:13:57 +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.43 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-7cedcea89a0so373413241.1; Sun, 14 Jan 2024 09:13:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705252435; x=1705857235; 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=8KtLxuXtJLa6q5hOOU3znGvv8eiYgnYhTPDMOOf+8Ug=; b=lSGhAKlGkaxl6ahTl2OOKKwFGYIXcQL/Zm66Tvg2qZYj6mynNazFVUAWECq34ILhRR N5lozOvgFYO86sszdD4YOHDTpxfzwzytV/O3qStjftTKUXO8b76RJakvoV7ciG6+W2oh GXqcWCSfEJjaiHL3gnOQdrX1ZYhDaWsn1O45vWDv/O54NJi3+w1JbJ5E3wg0NX8/luya 5d9YrWTNj1xKKl27HQjaBlyZJOn5Ggz9JHIYYccybGIFFZ1MDkYQe8Eh/pcROXmY8sAb IhZ+ZHOjAMt/arsq/HOCPZVe8f1J8aKHPNjFCydooZ7+GkQl937EZWJ4zr34twnfHoTG 1igA== X-Gm-Message-State: AOJu0YyvYhMgmSza1/J3ijNsVtgo4bDaf9Iq09kEitM64RMmSw1JFpAw EgEyKmXRojaCvgAxyAJsCQyrljqgPKNuGTGmc0A= X-Google-Smtp-Source: AGHT+IGu7ciQzRAfSv6ehTIw9it7Pq+YjIy+m2zJ6XjYBJ2IPVNy4rH28GXTlpVweCBK1scLyPzmYD9dEMvIdoq6chk= X-Received: by 2002:a67:ee04:0:b0:467:e9a2:ee0d with SMTP id f4-20020a67ee04000000b00467e9a2ee0dmr2130975vsp.34.1705252435413; Sun, 14 Jan 2024 09:13:55 -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 10:13:43 -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.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; 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.43: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.43:from] X-Rspamd-Queue-Id: 4TChh53f3xz4T8d On Sun, Jan 14, 2024 at 10:07=E2=80=AFAM Vin=C3=ADcius dos Santos Oliveira wrote: > > Em dom., 14 de jan. de 2024 =C3=A0s 13:30, Alan Somers > escreveu: > > I don't understand. What are you worried about that would block? > > lseek never does. It never actually goes to disk; it just retrieves a > > variable from within the kernel. So while the expense of a syscall is > > non-zero, you don't have to worry about lseek blocking. > > Sorry, that was a lot of condensed information that I dumped together. > > We can use lseek to get the offset and use AIO specifying the offset > we just queried. However the untrusted sandboxed process might > actually send as a socket file descriptor (we don't control what we > get from the untrusted sandboxed process), and lseek is then > inappropriate. In that case, I believe lseek should return ESPIPE. >From what I've read from the source code, we can pass > these bogus offsets to AIO, and it'll just work. However we're still > paying an extra syscall (and code doesn't feel right anyway). > > Anyway, the kernel *already* has this thread pool (AIO daemons), and > the only change required here is a flag that controls whether > FOF_OFFSET is passed along. That's a pretty non-invasive change. What > is the problem? Again, the model already works fine on Windows and > Linux. 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. -Alan 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/ From nobody Sun Jan 14 17:41:46 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 4TCjJL1xNwz56kj2 for ; Sun, 14 Jan 2024 17:41:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCjJK5L5Hz4Xlj; Sun, 14 Jan 2024 17:41:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 40EHfkic078560; Sun, 14 Jan 2024 19:41:49 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 40EHfkic078560 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 40EHfk4l078559; Sun, 14 Jan 2024 19:41:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 14 Jan 2024 19:41:46 +0200 From: Konstantin Belousov To: Alan Somers Cc: =?utf-8?B?Vmluw61jaXVz?= dos Santos Oliveira , freebsd-threads@freebsd.org, Konstantin Belousov Subject: Re: aio_read2() and aio_write2() Message-ID: References: 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4TCjJK5L5Hz4Xlj 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_RCPT(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Sun, Jan 14, 2024 at 10:13:43AM -0700, Alan Somers wrote: > On Sun, Jan 14, 2024 at 10:07 AM Vinícius dos Santos Oliveira > wrote: > > > > Em dom., 14 de jan. de 2024 às 13:30, Alan Somers > > escreveu: > > > I don't understand. What are you worried about that would block? > > > lseek never does. It never actually goes to disk; it just retrieves a > > > variable from within the kernel. So while the expense of a syscall is > > > non-zero, you don't have to worry about lseek blocking. > > > > Sorry, that was a lot of condensed information that I dumped together. > > > > We can use lseek to get the offset and use AIO specifying the offset > > we just queried. However the untrusted sandboxed process might > > actually send as a socket file descriptor (we don't control what we > > get from the untrusted sandboxed process), and lseek is then > > inappropriate. > > In that case, I believe lseek should return ESPIPE. You need seek cap rights to do lseek(2) on fd, which are specifically not included into cap rights needed for e.g. read(2) and write(2). > > >From what I've read from the source code, we can pass > > these bogus offsets to AIO, and it'll just work. However we're still > > paying an extra syscall (and code doesn't feel right anyway). > > > > Anyway, the kernel *already* has this thread pool (AIO daemons), and > > the only change required here is a flag that controls whether > > FOF_OFFSET is passed along. That's a pretty non-invasive change. What > > is the problem? Again, the model already works fine on Windows and > > Linux. > > 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. > > -Alan 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 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/