site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On May 10, 2006, at 12:03 PM, darwin-dev-request@lists.apple.com wrote: Date: Wed, 10 May 2006 11:02:13 +0200 From: Felix Schwarz <felix.schwarz@iospirit-gmbh.de> Subject: Shared mmap and data consistency upon a crash To: darwin-dev@lists.apple.com Message-ID: <4E6C2A59-FEEF-4E6C-88F6-27ECEAE2BD92@iospirit-gmbh.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello, I am currently exploring the possibilites to use mmap to speed up some of my most critical I/O, mmap() is a convenience interface, not a performance interface. but am wondering about the reliability of mmap and the durability of changes made to a file this way for one particular edge case: If 1) I mmap() a file using MAP_SHARED, PROT_READ and PROT_WRITE 2) I write into the returned address space 3) my app crashes prior to reaching munmap() and close() To me, it feels like you are trying to solve the wrong problems. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Stop right here. What makes you think that mmap will "speed up" your I/O? If you want to avoid blocking during I/O, consider the Posix asynchronous I/O system calls. If you want to avoid the copy in/out from kernel space, consider using the F_NOCACHE fcntl(2) option. If you control your caching behaviour and don't expect another process will access your file data, this is typically the most "performant" way to go. If your app crashes, all bets are off - assuming you don't know where it crashed, you have no guarantee as to the state of anything it was doing, regardless of whether it had files mapped or not. Typically, speaking as a developer, I find it's better to ship products that don't crash, rather than ones that are resistant to internal damage caused by crashes. This email sent to site_archiver@lists.apple.com