This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>>>>> 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |