[lttng-dev] URCU background threads vs signalfd
mathieu.desnoyers at efficios.com
Fri Sep 23 11:57:40 EDT 2022
On 2022-09-22 05:15, Eric Wong via lttng-dev wrote:
> Hello, I'm using urcu-bp + rculfhash + call_rcu to implement
> malloc instrumentation (via LD_PRELOAD) on an existing
> single-threaded Perl codebase which uses Linux signalfd.
> signalfd depends on signals being blocked in all threads
> of the process, otherwise threads with unblocked signals
> can receive them and starve the signalfd.
> While some threads in URCU do block signals (e.g. workqueue
> worker for rculfhash), the call_rcu thread and rculfhash
> partition_resize_helper threads do not...
> Should all threads URCU creates block signals (aside from SIGRCU)?
Yes, I think you are right. The SIGRCU signal is only needed for the
urcu-signal flavor though.
Would you like to submit a patch ?
> There might be other places, too, I haven't looked too closely...
> Anyways, I'm currently relying on this workaround to ensure
> initial calls to call_rcu and cds_lfht_resize are run with
> signals blocked:
> /* error-checking omitted for brevity */
> __attribute__((constructor)) static void my_ctor(void)
> sigset_t set, old;
> struct foo_hdr *h;
> pthread_sigmask(SIG_SETMASK, &set, &old);
> g_tbl = cds_lfht_new(8192, 1, 0, CDS_LFHT_AUTO_RESIZE, 0);
> h = malloc(sizeof(struct foo_hdr)));
> if (h) /* force call_rcu to start background thread */
> call_rcu(&h->as.dead, free_foo_hdr_rcu);
> /* start more background threads before unblocking signals */
> cds_lfht_resize(g_tbl, 16384);
> pthread_sigmask(SIG_SETMASK, &old, NULL);
> But I suspect it's better to ensure signals are blocked in all
> URCU-created threads...
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
More information about the lttng-dev