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