URCU feature request?

[Thobias Knudsen]

> 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20250902/938f4457/attachment-0001.htm>