Quoting Mathieu Desnoyers (2020-01-27 15:38:05) > ----- On Jan 23, 2020, at 7:19 PM, lttng-dev lttng-dev@lists.lttng.org wrote: > call_rcu() is meant to be async-signal-safe and lock-free after that > initialization has been performed on first use. Paul, do you know where > we have documented this in liburcu ?
Hm... reading it a little more carefully, it does seem that as long as you manually initialize it, then it is async-signal-safe afterwards. > > Also, I think it only makes sense to use call_rcu around a RCU write, > > which contradicts the README saying that only RCU reads are allowed in > > signal handlers. > > Not sure what you mean by "use call_rcu around a RCU write" ? I mean that in general, the pattern is usually to do an RCU write (to remove an item from a list, for example), then do call_rcu to aynchronously clean up the item. > Is there anything similar to sys_futex on FreeBSD ? Doing some more research, it seems that _umtx_op is allowed to be used by userspace applications, see https://patchwork.freedesktop.org/patch/200456/. So we can probably just use that. I'll send a patch shortly. > It would be good to look into alternative ways to fix this that do not > involve changing the guarantees provided by call_rcu() for that fallback > scenario (no futex available). Perhaps in your use-case you may want to > tweak the retry delay for compat_futex_async(). Currently > src/compat_futex.c:compat_futex_async() has a 10ms delay. Would 100ms > be more acceptable ? I don't completely understand what poll does here. Does it just mean that call_rcu callbacks would be delayed up to 100 ms? That's probably OK for cleanup uses, but I guess other uses may need faster reactions. _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
