From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 7 Nov 2014 12:44:25 +0300 From: Oleg To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20141107094425.GA29497@localhost> References: <20141106210544.GA20298@localhost> 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: 248bcac6-ead9-11e9-9d60-3106f5b1d025 On Fri, Nov 07, 2014 at 08:19:05AM +0000, Charles Forsyth wrote: > On 6 November 2014 21:05, Oleg wrote: > > > I looked at atexit() and atexitdont() and i don't understand why these > > functions are implemented with a static array instead of singly linked > > list? > > May be somebody with a greater plan9 experience can help me with my > > question. > > > > It might have been to avoid malloc in a fairly low-level function (and of > something that will never be freed), If 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. > or just because it was easier and, frankly, atexit let alone atexitdont > aren't used that much. I'd be surprised if > any use of atexit alone relied on any particular order, which is why your > problem hasn't been noticed. > The reverse order makes sense and atexit already does that. It's atexitdont > that's wrong. > The functions are unlikely to be called from any hot-spot. > I'd just make atexitdont copy down the entries after the one deleted. This is according to manual. Because now if we use atexit() with atexitdont() we see the wrong behaviour from manual point of view.