From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: [Xenomai-core] Automatic shadowing in POSIX lib constructor
Date: Fri, 21 Nov 2008 12:57:52 +0100 [thread overview]
Message-ID: <4926A240.6040709@domain.hid> (raw)
Hi Gilles,
as indicated in an earlier post, my customer managed to reveal some
issues around dlopen'ing Xenomai libs, more precisely libs that were
linked against libpthread_rt. The constructor of the POSIX lib has
several problems here, and I think some are not fixable:
o it auto-maps the constructor's caller even if it is not the main
thread, and before main() was called
o it ignores the caller's priority and sched policy, overwriting it
with SCHED_OTHER
o it removes mlockall from the process even if it was locked on entry
At least the last thing seems to be very hard to fix, but also for the
first item (testing if we are executed on application startup or later)
I see no solution right now.
So I propose to control automatic mapping as follows:
- rebrand --without-__thread as --enable-dlopen, keeping it off by
default
- continue to check for platform support of initial-exec TLS, only
use it when available *and* --enable-dlopen is not selected
- don't perform auto-mapping in __init_posix_interface if
--enable-dlopen is selected
This is build around the assumption that the user intentionally sets
--enable-dlopen because (s)he actually wants to use Xenomai libs like
that. And in that case (s)he is also expected to has a custom approach
which threads are shadowed (and with which priority) and which maybe not.
Comments? Better suggestions?
Jan
--
Siemens AG, Corporate Technology, CT SE 2 ES-OS
Corporate Competence Center Embedded Linux
next reply other threads:[~2008-11-21 11:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-21 11:57 Jan Kiszka [this message]
2008-11-21 13:56 ` [Xenomai-core] Automatic shadowing in POSIX lib constructor Gilles Chanteperdrix
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=4926A240.6040709@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=gilles.chanteperdrix@xenomai.org \
--cc=xenomai@xenomai.org \
/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.