Re: Synchronous method in asynchronous signal callback
Ray Strode <[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Message-ID | <CAA_UwzKcRq_Pq217QKk6XBnXqsSh0gP15dM8ofpKhZL1YP1t-g@mail.gmail.com> |
Hey, > GLib's "do not handle OOM" policy is correct for the 99% case. Many > who believe they should be handling OOM are probably wrong. And of > those who should be, many are probably making a token effort that's > broken in practice. Yea it turns out even the kernel just punts and calls the OOM killer for small allocations: https://lwn.net/Articles/627419/ Interesting excerpt: [changing the "too small to fail" behavior now] is scary for a couple of reasons. One is that not all kernel developers are diligent about checking every memory allocation and thinking about a proper recovery path. But it is worse than that: since small allocations do not fail, almost none of the thousands of error-recovery paths in the kernel now are ever exercised. They could be tested if developers were to make use of the the kernel's fault injection framework, but, in practice, it seems that few developers do so. So those error-recovery paths are not just unused and subject to bit rot; chances are that a discouragingly large portion of them have never been tested in the first place. If the unwritten "too small to fail" rule were to be repealed, all of those error-recovery paths would become live code for the first time. In a sense, the kernel would gain thousands of lines of untested code that only run in rare circumstances where things are already going wrong. There can be no doubt that a number of obscure bugs and potential security problems would result. _______________________________________________ dbus mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dbus