From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MGnAMA8At2hfPRIAWB0awg (envelope-from ) for ; Tue, 02 Sep 2025 10:32:47 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=lists.lttng.org header.i=@lists.lttng.org header.a=rsa-sha256 header.s=default header.b=b//e922S; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B13181E04C; Tue, 02 Sep 2025 10:32:47 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no autolearn_force=no version=4.0.1 Received: from lists.lttng.org (lists.lttng.org [158.69.130.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 022091E043 for ; Tue, 02 Sep 2025 10:32:46 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cGSrR3bySz17gC ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1756823559; b=aOggSPj/0ge7jjKJp2DpnABo1RuP6n74z+Qo4D6MOFr2ZvKlgkyIuz+n+obdidvMtvYG beuy+oV2QPrkJVzMaF2hNgxi2Ax1TWmXC36PidmpLjZ+zsEQ4rYEoFgfpTMjbLxGCCO/b wZsFwN7mGBnkDbyIDoGvdZNiYK3NtyxCFRs6phjent3WQp2RMceFCvmx7yKrnq0qYQBTP 87PP0AxeBpqjAiEs8Z9XjZ00y/d0iTG0jl2Q7PFAi2N63LbiPj/2kZpCZPBK9IJdI6+Si 5SBcqowvb93Hs1FfpzuPFDDE0e1+4J0PkdmW51uQyhMNVQlpuEGqnlzLemZ5ufCXTGw== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1756823559; h=DKIM-Signature:MIME-Version:Date:Message-ID:Subject:To:From:From; bh=VFkng/TchfNrH821lCdcSf4cypCiBTtvg1PGjSOvX0I=; b=K54KshvSH3YqOfOwyQrglTJSdqpjunM8RYS7jDVNyIm2QNjBiiBvTSlGeZ9iXiNmOGNc PG290cX2qXYD6nkO+BokkEKOiWHJOKCIjDluFocHnBVpWPU436RvegIzg14NBKo24oai7 zcZaoOsitiu1ilDf38fxxyJ4J1qoqe1mTG/5TPdsKWN+f10TKSMVBdDaTv3smFfv9CATn UMxR6Ygu+1JflaUvTwUOReRNog495P6olGxp2SEG3V5KeSvrVYdYD1p/RmuWbZUpawuDy aOkxYGUsDpR+FhumFaDA8u2keHnK8dsqdnvzNSvb4oeP2egCnrZl1DiMUkbKbdMPdrA== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cGSrR3bySz17gC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1756823559; bh=VFkng/TchfNrH821lCdcSf4cypCiBTtvg1PGjSOvX0I=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=b//e922SWobUK5xtxRtL9fdQP4UaqcNgP8kDKXBpOp343Uffc8S7Ksy0chHqPHHCi c/xD4qsCZhupI5/Lf+eh4AhaIzJ05TiJriFZMijJR55jXBfkJFsiKmrfZeIpYMgGWV Y9VfpPt13YBiQ5QomL1D88wWKqDSj44nTh0qAD1GY9EEAM6j6BE56noiLzj6SvkYz2 3izirheURnLILi43ELkD9KrZi6aSXdwfgYs/d7ItGibGIjz3qYokDlAOFzBRM2ANom FJUJueFyQBlXO4kILgX2DRGgO6s4Tk3nGx/5Cw+UqZ5K228RnqLiVB4TRkx26jG3Cj zFj2BzBX8LI/g== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4cGSrR3bySz17gC; Tue, 2 Sep 2025 10:32:39 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cGSB010hzz16x6 DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cGSB010hzz16x6 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lists.lttng.org (Postfix) with ESMTPS id 4cGSB010hzz16x6 for ; Tue, 2 Sep 2025 10:02:47 -0400 (EDT) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-61e8fe26614so4404171a12.1 for ; Tue, 02 Sep 2025 07:02:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756821762; x=1757426562; h=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=jph+c5TgRAhXM2HFVXHjP1YBM0x+pQHIYSQ6zhVfkIg=; b=WFO5XFZ5XUIa6MDfoiMSaKM6tdD9y/SWE+WTYe8S7p83QzvIsdXthMjXslT3EWf37i Y8Z0lJDphEOe1DwgN1H0GPOtw0iGlabv1mwHQu8VYwNnGTIQUpUR9uZv9EmrE/oVqUtD mLswMLKxTgpoQwJ76SObQw+nJjErrWkc/h6SirfgWbXKun3HklFj9LhNHWesp9+vhIK+ pYgg6muEx1gUQHF3UIt72EweglVa5khzDBaidm88UJJcB7omQQdGuQhnrlnMSd74SKZz hMjuTBgcgQSBU624DnVrmWcAcxT1XoTld2dFrn6ZW+hgifm7Ho2OPM2oKFT/AnmC4ZYP ho7w== X-Forwarded-Encrypted: i=1; AJvYcCX7tNH7kECZLe28adtt/q/rODyumABIWOHIjj0umeprhTDpvcipdrcOWkNnEeq9+XjhM4q7cY7ZRJ0=@lists.lttng.org X-Gm-Message-State: AOJu0YzYvkOx5DhNLqsQaAkxYUPtWZawx18arCZPQGEFWGxetGLENwQe QzzV0VFjpCRZ4oGaFPuRGnySVEoSV5Yq3bAuGAFbgv44XnaRzJGWXTRCTyqih7Cd6Sv3wHTzVq0 YnTS7s52xosdR5aI2JQebejdySGj87nzQ+oFl X-Gm-Gg: ASbGncsz3DxtBYdLMHkK8VYToozhp33JtsJTmuQ5JNYO2TafaHmC4vI6fpFg+SU0pqO cx/i+Gpjo+pwtFUPg87Yr7CVrmDonc/7/u9wJf0nxwRjHabB12d1AbexOtasb6gBU3B1Wr/uzXR 2+wnN2r98namxtD/qbmCZFXR+Wi2a3+JH7EkA0xFCNa0mwlz/iueKPn/sBsAR1SW+HzpSY8KoYF tLvV4Avfrx1D5lkdSk= X-Google-Smtp-Source: AGHT+IFKMhzecr0nqUTaixsn2f/8dWIMo/YlowjG7tsPDiUk4rATQ9Q4sB4MTynEzJJyFFiq0aEwMmexpMcZbGVHa/g= X-Received: by 2002:a05:6402:3228:b0:61c:c086:e2a0 with SMTP id 4fb4d7f45d1cf-61d26c3fbedmr13870826a12.24.1756821759834; Tue, 02 Sep 2025 07:02:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 2 Sep 2025 16:02:28 +0200 X-Gm-Features: Ac12FXzJFx-nK2dEBIPYGuR-I03xMIGIQHAOEkEJqAc1SEdBPhL2OTUkojNT4TY Message-ID: Subject: Re: URCU feature request? To: Mathieu Desnoyers Content-Type: multipart/alternative; boundary="000000000000edbd85063dd1f0ee" X-Mailman-Approved-At: Tue, 02 Sep 2025 10:32:38 -0400 X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Thobias Knudsen via lttng-dev Reply-To: Thobias Knudsen Cc: Olivier Dion , lttng-dev@lists.lttng.org, paulmck Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" --000000000000edbd85063dd1f0ee Content-Type: text/plain; charset="UTF-8" > github repo is only a mirror. From the README.md you will notice a > link to: > > Bug tracker: [Userspace RCU bug tracker]( https://bugs.lttng.org/projects/urcu) > > which has a "Feature" category. Yes I actually visited that page. I just forgot to mention it. But I couldn't create a feature request. I guess I have to create an account then? I tried to create an account now and I have to wait for it to be verified. Why isn't the issues just on github instead as people are more familiar with that? > The flag approach would allow your application to eventually complete, > which may not be the case if you endlessly wait for all callbacks to > be completed without preventing further callbacks to be enqueued. In my case I have made a wrapper over cds_lfht which allows for recursive lfht inside each other. for all lfht nodes there is a callback function which in turn calls call_rcu on all the children lfht nodes. That means the number of rcu_barriers needed to be called at program exit is the same as the depth of lfht nodes. In this case there will never be an infinite callback chain so if I understood correctly then I don't think using a flag is relevant. I could iterate over every node to check the max depth but that seems dirty. Isn't there an internal variable to check for how many callbacks are left or if there are any at all? Or maybe it's unsafe to access it? man. 1. sep. 2025 kl. 17:04 skrev Mathieu Desnoyers < mathieu.desnoyers@efficios.com>: > On 2025-08-31 16:42, Thobias Knudsen wrote: > > First question: why isn't Userspace RCU more popular? > > One guess is that for many use-cases, locking is sufficient. > > RCU and lock-free data structures are relevant in performance, latency, > and scalability sensitive use-cases. > > And of course we could probably do a better job at advertising its > existence. > > > Second question: Why isn't it possible to create issues in the urcu > > repo? > > github repo is only a mirror. From the README.md you will notice a > link to: > > Bug tracker: [Userspace RCU bug tracker]( > https://bugs.lttng.org/projects/urcu) > > which has a "Feature" category. > > > Im asking for a feature here: > > Is it possible to make a function which checks if there are more > > callbacks queued by call_rcu? I need that because there are some > > callbacks which call call_rcu, and then calling rcu_barrier once > > isn't enough and I therefore need a way to check if there are still > > callbacks to wait on before terminating the program. No worries if this > > is too much to ask for or if it isn't possible. This functionality is > > only needed in termination because otherwise isn't needed to call > > rcu_barrier multiple times (at least so far) > > Here is a relevant comment at the top of urcu_call_rcu_exit: > > * Here is how an application can ensure graceful teardown of this > * worker thread: > * > * - An application queuing call_rcu callbacks should invoke > * rcu_barrier() before it exits. > * - When chaining call_rcu callbacks, the number of calls to > * rcu_barrier() on application exit must match at least the maximum > * number of chained callbacks. > * - If an application chains callbacks endlessly, it would have to be > * modified to stop chaining callbacks when it detects an application > * exit (e.g. with a flag), and wait for quiescence with rcu_barrier() > * after setting that flag. > * - The statements above apply to a library which queues call_rcu > * callbacks, only it needs to invoke rcu_barrier in its library > * destructor. > > The flag approach would allow your application to eventually complete, > which may not be the case if you endlessly wait for all callbacks to > be completed without preventing further callbacks to be enqueued. > > Ideally please include the lttng-dev mailing list on those discussions > in the future, so everyone can benefit from them. > > Thanks, > > Mathieu > > > > > Best regards > > Thobias > > > > > > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com > --000000000000edbd85063dd1f0ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> github repo is only a mirror. From the README.md= you will notice a
> link to:
>=C2=A0
> Bug tracker: [Use= rspace RCU bug tracker](https://bugs.lttng.org/projects/urcu= )
>=C2=A0
> which has a "Feature" categ= ory.

Yes I actually visited that page. I just forg= ot to mention it. But I couldn't create a feature request. I guess I ha= ve to create an account then? I tried to create an account now and I have t= o wait for it to be verified. Why isn't the issues just on github inste= ad as people are more familiar with that?

> The flag= approach would allow your application to eventually complete,
> whic= h may not be the case if you endlessly wait for all callbacks to
> be= completed without preventing further callbacks to be enqueued.

In my case I have made a wrapper over cds_lfht which allows=C2=A0fo= r recursive lfht inside each other. for all lfht=C2=A0nodes there is a call= back function which in turn calls call_rcu on all the children lfht nodes. = That means the number of rcu_barriers needed to be called at program exit i= s the same as the depth of lfht=C2=A0nodes. In this case there will never b= e an infinite callback chain so if I understood correctly then I don't = think using a flag is relevant. I could iterate over every node to check th= e max depth but that seems dirty. Isn't there an internal variable to c= heck for how many callbacks are left or if there are any at all? Or maybe i= t's unsafe to access it?=C2=A0

man. 1. sep. = 2025 kl. 17:04 skrev Mathieu Desnoyers <mathieu.desnoyers@efficios.com>:
On 2025-08-31 16:42, Thobias Knud= sen wrote:
> First question: why isn't Userspace RCU more popular?

One guess is that for many use-cases, locking is sufficient.

RCU and lock-free data structures are relevant in performance, latency,
and scalability sensitive use-cases.

And of course we could probably do a better job at advertising its
existence.

> Second question: Why isn't it possible to create issues in the urc= u
> repo?

github repo is only a mirror. From the README.md you will notice a
link to:

Bug tracker: [Userspace RCU bug tracker](https://bugs.lttng.org/= projects/urcu)

which has a "Feature" category.

> Im asking for a feature here:
> Is it possible to make a function which checks if there are more
> callbacks queued by call_rcu? I need that because there are some
> callbacks which call call_rcu, and then calling rcu_barrier once
> isn't=C2=A0enough and I therefore need a way to check if there are= still
> callbacks to wait on before terminating the program. No worries if thi= s
> is too much to ask for or if it isn't=C2=A0possible. This function= ality is
> only needed in termination because otherwise isn't=C2=A0needed to = call
> rcu_barrier multiple times (at least so far)

Here is a relevant comment at the top of urcu_call_rcu_exit:

=C2=A0 * Here is how an application can ensure graceful teardown of this =C2=A0 * worker thread:
=C2=A0 *
=C2=A0 * - An application queuing call_rcu callbacks should invoke
=C2=A0 *=C2=A0 =C2=A0rcu_barrier() before it exits.
=C2=A0 * - When chaining call_rcu callbacks, the number of calls to
=C2=A0 *=C2=A0 =C2=A0rcu_barrier() on application exit must match at least = the maximum
=C2=A0 *=C2=A0 =C2=A0number of chained callbacks.
=C2=A0 * - If an application chains callbacks endlessly, it would have to b= e
=C2=A0 *=C2=A0 =C2=A0modified to stop chaining callbacks when it detects an= application
=C2=A0 *=C2=A0 =C2=A0exit (e.g. with a flag), and wait for quiescence with = rcu_barrier()
=C2=A0 *=C2=A0 =C2=A0after setting that flag.
=C2=A0 * - The statements above apply to a library which queues call_rcu =C2=A0 *=C2=A0 =C2=A0callbacks, only it needs to invoke rcu_barrier in its = library
=C2=A0 *=C2=A0 =C2=A0destructor.

The flag approach would allow your application to eventually complete,
which may not be the case if you endlessly wait for all callbacks to
be completed without preventing further callbacks to be enqueued.

Ideally please include the lttng-dev mailing list on those discussions
in the future, so everyone can benefit from them.

Thanks,

Mathieu

>
> Best regards
> Thobias
>
>


--
Mathieu Desnoyers
EfficiOS Inc.
h= ttps://www.efficios.com
--000000000000edbd85063dd1f0ee--