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 11:40:58AM +0530, Siddhesh Poyarekar wrote:
> On 6 March 2013 05:13, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> > It would be *really* convenent if snprintf could be split into the
> > "regular" snprintf, and a snprintf_nomalloc(). The latter would return
> > ENOMEM if malloc was actually required.
>
> snprintf could use mmap directly, which is slow but at least does not
> fail when there is memory available. The alloca cutoff threshold is
> currently 64K, so the mmap requests would be a minimum of 16 pages,
> with the worst case for space wastage being about 6.25% of the request
> (65537 bytes requested and given 69632). That way there's no need for
> such a special case function.
>
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.
> We could also have a magic environment variable that allows the code
> to use malloc instead, reverting to old behaviour ;)
>
I do not see how this could be useful except for small performance
benefit.
>
> Siddhesh
> --
> http://siddhesh.in
--
We're out of slots on the server