[lttng-dev] URCU background threads vs signalfd

[Eric Wong]

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)?

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;

	sigfillset(&set);
	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...

Thanks.