This is the mail archive of the 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: [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 <> 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..


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]