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]

Re: fork() and syslog() locks each other. How to avoid?


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]