* is dl_iterate_phdr() supposed to be async-signal safe?
@ 2004-04-01 7:50 David Mosberger
2004-04-01 21:22 ` Roland McGrath
0 siblings, 1 reply; 4+ messages in thread
From: David Mosberger @ 2004-04-01 7:50 UTC (permalink / raw)
To: libc-hacker
Subject pretty much says it all: I thought it was meant to be
async-signal safe but looking at the __pthread_mutex_lock() code, it
pretty clearly can't be, since it's updating the count and ownership
members non-atomically with respect to signal-delivery. Or am I
missing something?
So much for dl_iterate_phdr() being an "obvious" interface... ;-/
--david
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: is dl_iterate_phdr() supposed to be async-signal safe?
2004-04-01 7:50 is dl_iterate_phdr() supposed to be async-signal safe? David Mosberger
@ 2004-04-01 21:22 ` Roland McGrath
2004-04-02 0:09 ` David Mosberger
0 siblings, 1 reply; 4+ messages in thread
From: Roland McGrath @ 2004-04-01 21:22 UTC (permalink / raw)
To: davidm; +Cc: libc-hacker
Why would you have thought that it was? It is well-specified that no
interface is async-signal-safe unless explicitly listed as such. No such
claim was ever made about dl_iterate_phdr.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: is dl_iterate_phdr() supposed to be async-signal safe?
2004-04-01 21:22 ` Roland McGrath
@ 2004-04-02 0:09 ` David Mosberger
2004-04-19 18:39 ` what to do about dl_iterate_phdr() David Mosberger
0 siblings, 1 reply; 4+ messages in thread
From: David Mosberger @ 2004-04-02 0:09 UTC (permalink / raw)
To: Roland McGrath; +Cc: davidm, libc-hacker
>>>>> On Thu, 1 Apr 2004 13:22:03 -0800, Roland McGrath <roland@redhat.com> said:
Roland> Why would you have thought that it was? It is
Roland> well-specified that no interface is async-signal-safe unless
Roland> explicitly listed as such. No such claim was ever made
Roland> about dl_iterate_phdr.
Because otherwise there is no way to unwind from a signal handler and
I was mislead by the fact that it was using a recursive lock (and it
was only indirectly calling pthread_mutex_lock(), which is defined not
to be async-signal safe).
Can this please be fixed? Wouldn't it be sufficient to disable signal
delivery during lock acquisition/release and while modifying the ELF
object list?
--david
^ permalink raw reply [flat|nested] 4+ messages in thread
* what to do about dl_iterate_phdr()
2004-04-02 0:09 ` David Mosberger
@ 2004-04-19 18:39 ` David Mosberger
0 siblings, 0 replies; 4+ messages in thread
From: David Mosberger @ 2004-04-19 18:39 UTC (permalink / raw)
To: libc-hacker; +Cc: davidm
dl_iterate_phdr() isn't signal-safe and therefore there is currently
no way to safely unwind out of a signal-handler. My proposal to make
dl_iterate_phdr() async-signal-safe seems to have fallen on deaf ears.
So what's your position? Is the official position that glibc simply
cannot safely unwind out of a signal handler or do you have an
alternate proposal in mind?
Thanks,
--david
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-04-19 18:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-01 7:50 is dl_iterate_phdr() supposed to be async-signal safe? David Mosberger
2004-04-01 21:22 ` Roland McGrath
2004-04-02 0:09 ` David Mosberger
2004-04-19 18:39 ` what to do about dl_iterate_phdr() David Mosberger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).