From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20141107094425.GA29497@localhost> References: <20141106210544.GA20298@localhost> <20141107094425.GA29497@localhost> Date: Fri, 7 Nov 2014 10:22:26 +0000 Message-ID: From: Charles Forsyth To: Oleg , Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=f46d043be1d2868b2a05074230e4 Subject: Re: [9fans] atexit() & atexitdont() Topicbox-Message-UUID: 249041aa-ead9-11e9-9d60-3106f5b1d025 --f46d043be1d2868b2a05074230e4 Content-Type: text/plain; charset=UTF-8 On 7 November 2014 09:44, Oleg wrote: > f malloc works like in linux (at first invocation allocate more bytes than > requested and then each malloc() use this already allocated by kernel area > of memory), i think this isn't a big performance impact. > I wasn't really thinking about performance; as I said it's unlikely to be in a critical path. This is according to manual. Because now if we use atexit() with > atexitdont() > we see the wrong behaviour from manual point of view. Yes, that's why I suggested fixing atexitdont to move any remaining values down the array. --f46d043be1d2868b2a05074230e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 7 November 2014 09:44, Oleg <lego12239@yandex.ru> wrote= :
f malloc works like in linux (at first invocation allocate more bytes than=
requested and then each malloc() use this already allocated by kernel area<= br> of memory), i think this isn't a big performance impact.

I wasn't really thinking about performance; as I said it&= #39;s unlikely to be in a critical path.
This is according to manual. Becau= se now if we use atexit() with atexitdont()
we se= e the wrong behaviour from manual point of view.
Yes, that's why I suggested fixing atexitdont to move any = remaining values down the array.
--f46d043be1d2868b2a05074230e4--