From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Pavel Machek <pavel@ucw.cz>, carlos <carlos@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Boqun Feng <boqun.feng@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
libc-alpha <libc-alpha@sourceware.org>
Subject: Re: Restartable Sequences system call merged into Linux
Date: Fri, 15 Jun 2018 13:50:17 -0400 (EDT) [thread overview]
Message-ID: <422468177.14427.1529085017684.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <b5c0a91b-b428-7807-0f16-97f15e632bdb@redhat.com>
----- On Jun 15, 2018, at 1:09 AM, Florian Weimer fweimer@redhat.com wrote:
> On 06/14/2018 03:01 PM, Mathieu Desnoyers wrote:
>> Another alternative would be to somehow let glibc handle the registration,
>> perhaps only doing it for applications expressing their interest for rseq.
>
> That's not really possible. We can't rely on the visibility of symbol
> bindings due to lazy binding and hidden visibility. Registration of
> intent by other means will not work because if it is done from user
> code, some other library may have already launched a thread at this point.
>
> (It's also a moot point if we want to use restartable sequences in glibc
> itself.)
Considering that we can expect the glibc memory allocator to benefit from
rseq to speed up its memory allocator, this means pretty much any application
linked against glibc *will* end up using rseq indirectly.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2018-06-15 17:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-11 19:49 Restartable Sequences system call merged into Linux Mathieu Desnoyers
2018-06-11 19:55 ` Florian Weimer
2018-06-11 20:04 ` Mathieu Desnoyers
2018-06-12 13:11 ` Florian Weimer
2018-06-12 16:31 ` Mathieu Desnoyers
2018-06-13 8:21 ` Florian Weimer
2018-06-14 12:27 ` Pavel Machek
2018-06-14 13:01 ` Mathieu Desnoyers
2018-06-14 13:25 ` Pavel Machek
2018-06-14 13:32 ` Florian Weimer
2018-06-14 13:46 ` Mathieu Desnoyers
2018-06-15 5:10 ` Florian Weimer
2018-06-15 17:44 ` Mathieu Desnoyers
2018-06-14 13:38 ` Mathieu Desnoyers
2018-06-14 13:49 ` Pavel Machek
2018-06-14 14:00 ` Florian Weimer
2018-06-14 14:36 ` Mathieu Desnoyers
2018-06-14 14:41 ` Florian Weimer
2018-06-14 15:09 ` Mathieu Desnoyers
2018-06-15 5:09 ` Florian Weimer
2018-06-15 17:50 ` Mathieu Desnoyers [this message]
2018-06-15 5:07 ` Florian Weimer
2018-06-13 11:48 ` Heiko Carstens
2018-06-13 16:14 ` Mathieu Desnoyers
2018-06-13 19:53 ` Mathieu Desnoyers
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=422468177.14427.1529085017684.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=boqun.feng@gmail.com \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.