Suppressing SIGBUS signals

Posted Jun 26, 2021 2:04 UTC (Sat) by NYKevin (subscriber, #129325)
In reply to: Suppressing SIGBUS signals by sbaugh
Parent article: Suppressing SIGBUS signals

Meh, that's a matter of perspective. Crashing is only the default behavior, and they are working to make it easier to avoid crashing on OOM. There is no technical reason* why OOMing needs to crash, in a language with manual memory management. You could instead have fallible allocation and require the application to handle an OOM condition explicitly.

* You cannot control what the OOM killer does (although the sysadmin can, to some extent). But the OOM killer could even kill a completely unrelated process, and is not part of Rust itself, so let's ignore it. Besides, since Rust is a systems language, it can be used to write kernelspace code that is exempt from the OOM killer altogether.

to post comments

Suppressing SIGBUS signals

Posted Jun 27, 2021 5:57 UTC (Sun) by dancol (guest, #142293) [Link] (2 responses)

> why OOMing needs to crash, in a language with manual memory management. You could instead have fallible allocation and require the application to handle an OOM condition explicitly.

Not every system is an overcommit system. Windows isn't. Linux with vm.overcommit_memory=2 isn't either.

Anyway, Rust wouldn't be having this problem at all if it had just adopted exceptions for error handling.

Suppressing SIGBUS signals

Posted Jun 27, 2021 12:14 UTC (Sun) by mpr22 (subscriber, #60784) [Link]

> Anyway, Rust wouldn't be having this problem at all if it had just adopted exceptions for error handling.

I dare say it would be having others, though.

Suppressing SIGBUS signals

Posted Jun 27, 2021 21:26 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

> Not every system is an overcommit system. Windows isn't. Linux with vm.overcommit_memory=2 isn't either.

Yes, that's why I included the footnote about the OOM killer being out of scope. It's not part of Rust in the first place.