From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 7 Nov 2014 15:19:29 +0300 From: Oleg To: 9fans@9fans.net Message-ID: <20141107121929.GA10144@localhost> References: <20141106210544.GA20298@localhost> <20141107094425.GA29497@localhost> <20141107105708.cOSXGRv3%sdaoden@yandex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [9fans] atexit() & atexitdont() Topicbox-Message-UUID: 24f75a34-ead9-11e9-9d60-3106f5b1d025 On Fri, Nov 07, 2014 at 11:49:08AM +0000, Charles Forsyth wrote: > On 7 November 2014 10:57, Steffen Nurpmeso wrote: > > > Safety against asynchronous un-/registration can't be it, anyway. > > > No, there's a lock. I meant avoiding too many possible interactions between > low-level run-time > functions and the rest of the library. (I'd consider atexit and exit to be > lower-level functions than malloc.) > Since atexit is already used by profile, and is called by _profmain, which > is called very early on, > putting a call to malloc in that chain means you have to think that much > harder about interactions that are already quite subtle. This is an interesting. With this info the array reordering in atexitdont() looks good comparing to malloc in atexit().