> 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