On 05/15/2014 04:25 AM, Peter Zijlstra wrote: > On Wed, May 14, 2014 at 04:59:58PM -0400, Carlos O'Donell wrote: >> I will make my personal opinion clear: >> >> - Internal defects should raise immediate assertions. >> >> - Real problems like resource availability, deadlocks, and >> other recoverable errors should result in the API returning >> an appropriate error code that must not diverge from the POSIX >> definitions for those codes (when such a definition exists). >> >> I'm not a believer in "only the hot path matters", there are such >> things as robustness and error detection, and they matter. > > Awesome. In case of doubt though, I would prefer a return to an assert, > just in case userspace actually does know wtf its doing ;-)
No. In that case the person who knows attaches a debugger to determine why the internal state is inconsistent. That may require kernel or glibc debugging and asserting as close to the point of corruption is the only useful behaviour. I know it's painful, but the number of people who know what they are doing is vanishingly small compared to the other set. > Granted, that seems to be very rare, but still, its entirely annoying > for those few people who do care to get dead programs. > > Alternatively, we could have something like you have for the allocator > (which is, afaik, also considered a hot path) these env variables like > MALLOC_CHECK_ to influence this edge behaviour. We are considering a runtime tunnables framework to unify all of these kinds of tweaks into a stable API. Given that asserting or not asserting does not impact the standards conformance we could make that a tunnable with the default being to assert. The tunnables framework is still pie in the sky because we need a low-overhead framework to check the global tunnables. However, we need them, as I've mentioned before as an example we have an ancient 40MB stack cache in glibc for thread stack reuse that nobody remembers why it was tuned to that value. Magic. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
