msync() and subtle behavioral tweaks [LWN.net]

msync() and subtle behavioral tweaks

Posted Jun 22, 2012 17:51 UTC (Fri) by jmorris42 (subscriber, #2203)
Parent article: msync() and subtle behavioral tweaks

Maybe I'm missing something important but it sounds like these two changes make the system call behave more like the documentation. That should be a good thing and a no brainer.

The first change, causing it to actually get busy writing when the call is made but without blocking is kinda what you should have been expecting from explicitly making that call in the first place. The existing kernel behavior of basically ignoring the whole request is the error. If you could live with it getting written eventually when the system got around to it you could have skipped the call and got the same result.

Same for the range. It is actually implementing behavior that has long been documented in the API but left unwritten. Even if you have a bug and are specifying the range wrong you still get the same result you used to get, a write when the kernel gets a spare roundtuit. So all this is doing is increasing the odds that a range that is correctly specified will get written in the case of a crash. It could have happened before though and it might not, and it still might not get written. So all one can say is if you have buggy code it is possible you will get bitten a little more often with this change but probably all that will happen is you won't get as much of an improvement in reliability.

(Log in to post comments)

msync() and subtle behavioral tweaks

Posted Jun 26, 2012 19:14 UTC (Tue) by liljencrantz (subscriber, #28458) [Link]

I am surprised this did not come up in the article. Maintaining backward compatibility with possibly existing old programs is relevant, but is it really more important than making sure the kernel behavior matches the API documentation so that *future* programs will behave as expected?

The other alternative would of course be to deprecate the old calls and replace them with newer ones that do what you'd expect from the documentation and then carefully document all the ways in which the old syscalls don't actually do what they advertise. This alternative sounds horrible in a very Redmondesque way.