From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 080319EB63 for ; Fri, 3 Nov 2023 10:52:36 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DF24B1AD04 for ; Fri, 3 Nov 2023 10:52:05 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 3 Nov 2023 10:52:05 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 2F694441B9 for ; Fri, 3 Nov 2023 10:52:05 +0100 (CET) Date: Fri, 3 Nov 2023 10:52:04 +0100 From: Wolfgang Bumiller To: Gabriel Goller Cc: pbs-devel@lists.proxmox.com Message-ID: References: <20231025135325.198073-1-g.goller@proxmox.com> <20231025135325.198073-3-g.goller@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.103 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [RFC proxmox v2 2/2] proxmox-log: added tracing infra X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2023 09:52:36 -0000 On Fri, Nov 03, 2023 at 10:24:22AM +0100, Gabriel Goller wrote: > On 11/3/23 09:56, Wolfgang Bumiller wrote: > > > > > +} > > > > > + > > > > > +impl WorkerTaskFilter { > > > > > + pub fn new(in_worker_task: Arc>) -> WorkerTaskFilter { > > > > > + WorkerTaskFilter { in_worker_task } > > > > > + } > > > > > +} > > > > > + > > > > > +impl LookupSpan<'a>> Filter for WorkerTaskFilter { > > > > > + fn on_enter(&self, id: &span::Id, ctx: Context<'_, S>) { > > > > > + let metadata = ctx.metadata(id); > > > > > + if let Some(m) = metadata { > > > > > + if m.name() == "worker_task" { > > > > I'm not so happy with this. > > > > Now each time we poll a worker task we go through this layer system > > > > which uses string comparison to know whether we're currently in a worker > > > > task, for something that is actually rather static in the code. > > > > I'd much prefer a simply custom `Future` wrapping the worker task's > > > > future and setting this flag for the duration of the `poll()` method. > > > Ok, but the `Future` wrapper would only work for the task, right? > > I don't see the difference. In the threaded version you'd just > > initialize in_worker_task to `true` - I mean, it does not matter where > > you access that `Arc` from? > > > > I don't know. I find this whole thing a bit backwards? Maybe it's just > > me, but I'm not convinced that's how this part of `tracing` is meant to > > be used. > > > > Consider this: > > If you already have an Arc, all you need is a thread-local > > copy of it: > > - A Future based worker would have a wrapping Future containing that > > Arc, which, for the duration of `poll()`, sets the thread-local to > > point to its Arc. > > - A thread based worker would just set it at the very beginning. > > - A guard to enable/disable it (if we even need it, like on_enter/on_exit) > > would contain the old value and restore it on Drop (giving us a > > push/pop mechanics for cheap). > > > > Also note that AFAICT neither the current tracing variant nor what I > > wrote above deal with `tokio::spawn()`ed tasks, but that's fine. > > If we want the ability to inherit the logging facility, this would need > > to be independent from the boolean anyway since tasks can run on > > separate threads - unless we restrict it to `LocalSet`s. > > So I think we might need to first decide how that bit *should* work > > before adding the ability to enter/leave the scope at will. > > Unless I'm missing something. > To be honest, I don't really get the advantage of a Future-Wrapper? > Why not just have a: > ```rust > tokio::spawn(async move { ^ this async{} block up here should not be necessary, `.scope()` returns a future. >     LOGGER.scope(logger, async move { >         // worker logic >     }) > }) > ``` > and > ```rust > let _child = std::thread::Builder::new() >     .name(upid.clone()) >     .spawn(move || { >         LOGGER.sync_scope(logger, || { >             // worker logic >         }) >     }); It's essentially the same, so that's fine too. I'm guessing you intend to skip the boolean part then and only go with whether a logger is set?