3 ms·
When one says unsafe or safe, it's primarily about type safety and more so memory safety, so it depends if you consider OOM a violation of memory safety. If yo
by TheHydroImpulse 11y ago
When one says unsafe or safe, it's primarily about type safety and more so memory safety, so it depends if you consider OOM a violation of memory safety.
If you don't have a hard limit in terms of your buffer or memory allocations (and have an unlimited upper-bound) you'll be in trouble sooner or later. I'd argue that it would be a far more robust principle to institute an upper-bound than trying to catch OOM errors.
- mtanski 11y agoRust's goals are both type and memory safety. I consider an OOM with a panic/abort a memory safety issues. Linux also does these kinds of things to your process, but there at least you can opt out of it. I agree with you, in the real world you need some kind of well tuned upper limits above which you apply back pressure / start dropping connections. But in the absence of this the runtime should try to make every possible attempt at forward progress (even if we're just limping along).
- MichaelGG 11y agoHow is OOM unsafe? By that definition, all languages are unsafe. And note, this is waving over the real safety issues that C/C++ has, which allows small bugs to turn into remote shells.
- pcwalton 11y agoIt's not a memory safety issue any more than any other kind of abort is. If it were, abort would be marked unsafe. > But in the absence of this the runtime should try to make every possible attempt at forward progress (even if we're just limping along). So what is your proposal?