From: Eric Wong via lttng-dev <lttng-dev@lists.lttng.org>
To: lttng-dev@lists.lttng.org
Subject: [lttng-dev] URCU background threads vs signalfd
Date: Thu, 22 Sep 2022 09:15:36 +0000 [thread overview]
Message-ID: <20220922091536.GA4597@dcvr> (raw)
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.
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
next reply other threads:[~2022-09-22 9:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-22 9:15 Eric Wong via lttng-dev [this message]
2022-09-23 15:57 ` [lttng-dev] URCU background threads vs signalfd Mathieu Desnoyers via lttng-dev
2022-09-23 17:55 ` Eric Wong via lttng-dev
2022-09-23 18:24 ` Mathieu Desnoyers via lttng-dev
2022-09-23 22:05 ` Eric Wong via lttng-dev
2022-09-26 12:51 ` Mathieu Desnoyers via lttng-dev
2022-09-26 19:58 ` Eric Wong via lttng-dev
2022-09-26 20:12 ` Mathieu Desnoyers via lttng-dev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220922091536.GA4597@dcvr \
--to=lttng-dev@lists.lttng.org \
--cc=normalperson@yhbt.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox