From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 7 Nov 2014 20:25:19 +0100 From: Steffen Nurpmeso To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20141107192519.bpNJq1V1%sdaoden@yandex.com> References: <20141106210544.GA20298@localhost> <20141107094425.GA29497@localhost> <20141107105708.cOSXGRv3%sdaoden@yandex.com> In-Reply-To: User-Agent: s-nail v14.7.8-69-gf8bdb20 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [9fans] atexit() & atexitdont() Topicbox-Message-UUID: 253ca396-ead9-11e9-9d60-3106f5b1d025 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 I thought more about reentrancy because he referred to Linux. But of course you're right. |low-level run-time |functions and the rest of the library. (I'd consider atexit and exit to be |lower-level functions than malloc.) I do not really agree for the highly integrated and portable solution that i worked with, it was just fine there and splitted into normal and final handlers. But.. |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. |Note that _profmain allocates its memory directly using sbrk, probably for |that reason. |Suppose I later want to add a malloc profiler, can I call atexit to write |the results, or not? It seems you can add an atom and it works without spending any further thought. That is cool. --steffen