This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] signal-safe fprintf?
On Thu, Mar 07, 2013 at 03:10:29PM +0530, Siddhesh Poyarekar wrote:
> On 7 March 2013 14:12, OndÅej BÃlka <neleai@seznam.cz> wrote:
> > As threshold for mmap in malloc is 256k it would not make much
> > difference.
> >
> > Timewise it is dominated by printf printing 65537 characters or more.
> >
> > Problem with this approach is that it only shifts signal safety of mmap
> > which can be also overriden.
>
> Right, mmap is not guaranteed by the standard to be signal safe
> either, but it tends to work in practice compared to malloc.
>
> In fact, I just had a quick look at the vfprintf code and I think the
> malloc is not the only problem you'll have to work around. The
> vfprintf code locks the FILE, which can cause a deadlock if a signal
> handler was called with that lock held.
This is not a problem for the proposed usage, where the same FILE
would not be used in both places (one of the FILEs would be a
temp/dummy one created in snprintf). My only concern is whether
snprintf and dprintf add their dummy FILE to the global open file
list, which also involves locking. I seem to remember at least dprintf
doing this, but I may be mistaken..
Rich