This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
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 2006-09-24 at 09:01 +0200, Jakub Jelinek wrote: > On Sat, Sep 23, 2006 at 07:23:07PM +0400, Peter Volkov (pva) wrote: > > Thank you very much for your answer! It points me to the right > > direction. Both syslog() and fork() is non-reentrant functions so if I > > Wrong. fork() is async-signal-safe, only syslog is not. > See > http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04_03 Right. I've missed fork() during my attempts to understand program behavior. But then how can you comment initial backtrace? Is it intentional that calling fork() takes mutex? And related question: Can I ask glibc to check such kinds of calls in callback? /* Seems that it is possible: For example, wrap call to all callback functions and set semaphore there; then it's possible to check for semaphore in syslog and similar functions. Thus each such bad call could be easily seen. I understand about performance implications and thus of course this should be enabled/disabled during glibc build time. Are similar things implemented? If so I'd like to use them in my development chroot. */ > > really want to use syslog from signal handler I have to wrap all > > non-reentrant functions with futex's or may be use some global variable > > to avoid simultaneous calls to this functions. > > That won't help you. Yes. Let's follow posix. Thank you for your time, Peter.
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |