Re: fopen from within a pthread

[Martin Beynon <mebeyn@gmail.com>]

Thanks Carlos (and Paul),

I am aware of this...what I wasn't aware of was thread specific arenas.

However that said and understood...it does generate a couple of questions
in my mind:

1) Why doesn't the main program [thread] allocate a 64MB arena? In that
little test program I posted the heap is only 132KB; which leaves me to
wonder why can't the same approach be used for child threads? If I reduce
the MALLOC_ARENA_MAX to 1, the [virtual] memory consumption is the same for
both tests (fopen in thread or in main)...

2) Why can't the initial / default [thread-specific] arena size be changed?

Cheers,

Martin

On 4 June 2018 at 15:38, Carlos O'Donell <carlos@redhat.com> wrote:

> On 06/02/2018 06:48 PM, Paul Pluzhnikov via libc-help wrote:
> > On Sat, Jun 2, 2018 at 3:31 PM Martin Beynon <mebeyn@gmail.com> wrote:
> >>
> >> Is this erroneous behaviour, or can this be explained in some way?
> >
> >
> > There is nothing erroneous about it.
> >
> > What you are observing is the creation of thread-specific arena, from
> > which malloc will return memory to the new thread.
> >
> > GLIBC uses thread-specific arenas to avoid having to lock malloc
> > internal structures when multiple threads allocate and free memory.
> > Additional info can be found here:
> > https://sourceware.org/glibc/wiki/MallocInternals
>
> Also note that VM size is not the same as RSS.
>
> The new thread arena, usually ~64MiB in size on 64-bit, is only taking
> up VM space, but not consuming any real memory (RSS).
>
> Therefore this is just an accounting procedure. Real memory will only
> be used as you dirty the pages.
>
> Cheers,
> Carlos.
>
>