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/