RE: Shared mmap and data consistency upon a crash
RE: Shared mmap and data consistency upon a crash
- Subject: RE: Shared mmap and data consistency upon a crash
- From: Michael Smith <email@hidden>
- Date: Wed, 10 May 2006 12:28:48 -0700
On May 10, 2006, at 12:03 PM, email@hidden wrote:
Date: Wed, 10 May 2006 11:02:13 +0200
From: Felix Schwarz <email@hidden>
Subject: Shared mmap and data consistency upon a crash
To: email@hidden
Message-ID: <email@hidden>
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,
Stop right here. What makes you think that mmap will "speed up" your
I/O?
mmap() is a convenience interface, not a performance interface.
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.
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()
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.
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden