From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 22 Dec 2008 10:02:48 +0000 From: "roger peppe" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <42fe5d2488144155692f859a62a64b07@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1229835929.11463.55.camel@goose.sun.com> <42fe5d2488144155692f859a62a64b07@quanstro.net> Subject: Re: [9fans] 9pfuse and O_APPEND Topicbox-Message-UUID: 6bc60244-ead4-11e9-9d60-3106f5b1d025 On Sun, Dec 21, 2008 at 2:45 PM, erik quanstrom wrote: > okay, so you're using DMAPPEND like sbrk(2). how do you avoid > clients caring about the address of this new hunk of memory?^u > clients caring about the offset of this hunk of the file? > that is, the same problem malloc has in a multi-threaded app > with sbrk. in google's filesystem, i believe a write returns the offset it actually wrote at. if 9p was extended to do that, maybe per-fid append semantics might be more useful. (although if appending writes were rare enough, i suppose you could write the block with a unique identifier and scan to find where it actually ended up)