From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pbs-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
by lore.proxmox.com (Postfix) with ESMTPS id E96D41FF187
for <inbox@lore.proxmox.com>; Wed, 9 Apr 2025 16:28:01 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id CA77FA51A;
Wed, 9 Apr 2025 16:27:27 +0200 (CEST)
Message-ID: <1d61fea1-db7e-4615-8330-250b862a226f@proxmox.com>
Date: Wed, 9 Apr 2025 16:27:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>, Max Carrara <m.carrara@proxmox.com>
References: <20250408125839.196668-1-c.ebner@proxmox.com>
<20250408125839.196668-5-c.ebner@proxmox.com>
<D925PBMYWMNL.SUU07VVP4K@proxmox.com>
Content-Language: en-US, de-DE
From: Christian Ebner <c.ebner@proxmox.com>
In-Reply-To: <D925PBMYWMNL.SUU07VVP4K@proxmox.com>
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.030 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: Re: [pbs-devel] [PATCH v4 proxmox-backup 4/5] client: reader: add
finish method to signal client state to server
X-BeenThere: pbs-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Backup Server development discussion
<pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: pbs-devel-bounces@lists.proxmox.com
Sender: "pbs-devel" <pbs-devel-bounces@lists.proxmox.com>
On 4/9/25 15:53, Max Carrara wrote:
> On Tue Apr 8, 2025 at 2:58 PM CEST, Christian Ebner wrote:
>> Signal the server that the client has finished its operation and is
>> about to close the connection. This allows the server side to react
>> accordingly.
>>
>> Termination of the reader connection after successuful completion is
>> now no longer logged as connection error, which has caused confusion
>> [0].
>>
>> Report in the community forum:
>> [0] https://forum.proxmox.com/threads/158306/
>>
>> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
>> ---
>> changes since version 3:
>> - no changes
>>
>> pbs-client/src/backup_reader.rs | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/pbs-client/src/backup_reader.rs b/pbs-client/src/backup_reader.rs
>> index 18442ebca..3474c8ce3 100644
>> --- a/pbs-client/src/backup_reader.rs
>> +++ b/pbs-client/src/backup_reader.rs
>> @@ -77,6 +77,12 @@ impl BackupReader {
>> Ok(BackupReader::new(h2, abort, crypt_config))
>> }
>>
>> + /// Terminate reader session by signaling server via `finish` api call before closing connection
>> + pub async fn finish(self: Arc<Self>) -> Result<(), Error> {
>> + let _value = self.post("finish", None).await?;
>> + Ok(())
>> + }
>
> There are two concerns I have with this approach here:
>
> 1. While I like moving out of `self` here (I actually love it when
> state is represented via the type system) calling `post` here like
> this might cause a race: `self: Arc<Self>` might still be
> referenced somewhere else, as in, there might still be some other
> operations going on.
>
> 2. Calling `finish()` is not enforced. In patch 05 you're calling
> `finish()` in 9 locations in total if I counted correctly, which
> means that there are 9 locations where haphazard changes could
> introduce subtle bugs.
>
> What I'd instead suggest is enforcing the call to happen through the
> type system -- here's a *very* rough example:
>
> with_new_reader(..., |reader: &BackupReader| {
> // Do stuff in here ...
>
> // Return a result upon successful completion, which then signals
> // to with_new_reader() that finish() should be called
> Ok(...)
> })
>
> fn with_new_reader<F>(..., func: F) -> Result<(), Error>
> where
> F: FnOnce(BackupReader) -> Result<(), Error> {
>
> // [...] set up reader, then call func() on it
> let reader = ...
>
> match func(&reader) {
> Ok(()) => reader.finish().await,
> Err(...) => ...,
> }
> }
>
> The idea behind this is that the closure enforces the scope in which the
> reader is used for operations. Once the closure ends, `finish()` is
> called depending on the result the closure returns. Instead of just
> returning `()`, you could also add some kind of enum representing the
> possible "exiting" values / states of the reader, in case there's more
> stuff to handle (now or in the future).
>
> The thing is though... implementing this would require a rather large
> set of changes throughout our code, because we currently pass around
> `Arc<BackupReader>` quite a lot (*sigh*), which really gets in the way
> when one wants to enforce a certain order of operations (i.e. preventing
> `finish()` from being called too early).
>
> Since all of the methods of `BackupReader` take `&self` you could check
> if you can get away with s/Arc<BackupReader>/&BackupReader/.
>
> Let me know what you think!
Thanks for your suggestions. Given that this will however require more
in-depth changes and has a larger regression potential this will be
postponed to after the next point release (as discussed of list with
Thomas).
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel