On Mon, 2026-06-22 at 20:46 +0200, Danilo Krummrich wrote:
> On Mon Jun 22, 2026 at 7:32 PM CEST, Philipp Stanner wrote:
> > +/// Wait for one RCU grace period.
> > +///
> > +/// You typically do this to wait for everyone holding a [`Guard`].
>
> NIT: "typically" reads a bit as if there were other reasons to call
> synchronize_rcu() than to wait for all concurrent RCU read side critical
> sections.
The reason I wrote "typically" is because my mind had the potential
future use-case of ours prefetched where we might have to do a
synchronize_rcu() to wait for a C backend to be done with something,
where no one really holds a Rust `Guard` (though of course the read
lock).
>
> Also, while it's implicit, it might still be worth to explicitly call out that
> this means concurrently held Guard objects (concurrent read side critical
> sections), i.e. subsequent read side critical sections may still run
> concurrently.
That's quite generic RCU knowledge IMO. I'm not sure to what degree one
wants to document RCU in general at this new function here, vs just the
Rust API.
Rewording the documentation is fine by me, but since we're in a nitty
domain here I would then ask you to provide a few draft sentences that
would satisfy your basic requirements.
P.
>
> > +#[inline]
> > +pub fn synchronize_rcu() {
> > + // SAFETY: `synchronize_rcu()` is always safe to be called. It just
> > waits for a grace period.
> > + unsafe { bindings::synchronize_rcu() };
> > +}
> > --
> > 2.54.0
