From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 4 Apr 2011 19:17:40 -0400 To: 9fans@9fans.net Message-ID: <224a2b9fd0b816400c0e5690336df9f9@brasstown.quanstro.net> In-Reply-To: References: <20110403211333.GA3905@dinah> <946377fc99d55f66708553c16bb698de@coraid.com> <9739a352230f78fcb10629cdbc856dfc@ladd.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go Plan 9 Topicbox-Message-UUID: c91bfa00-ead6-11e9-9d60-3106f5b1d025 > Sorry, Erik, I misunderstood your point. no need to be sorry. > I guess what you are pointing out is that on Plan 9, presumably, since > the Go runtime is the only thing that might call brk(), it will always > get a virtually contiguous heap. Therefore, instead of a huge upfront > allocation, Go runtime could call brk() as needed. > > Can we safely assume that only the Go runtime will call brk()? What if > we link a library into Go that calls brk() as well -- won't that > violate Go's model? Probably not worth worrying about since Russ says > he's good with the other change. i didn't think of that, but i wouldn't think one would want to do that. the effort, say, to glue ndb structures into go's world would seem on par with rewriting the library. and it would be a great oppertunity to clean up some crunch. one big challenge in gluing in c libraries is that you couldn't easily pass any sort of pointer back in from c. it would break the gc. - erik