Concurrency in Rust

Re:Concurrency in Rust by nitrogen on Sunday March 27, 2016 @05:10PM (#11371571)

While quotemstr's reaction is over the top, I do see the need to have a memory allocation approach that can handle OOM gracefully. Many types of software that could benefit from Rust's compile-time safety will want to allocate right up to the limit of available memory, such as audio/video processing software where more memory equals more simultaneous effects and less I/O.

I am endlessly frustrated by poorly designed audio software that aborts without saving if an OOM occurs. At the very least, a process should have the oppprtunity to save its state to disk, or ideally continue operating at a reduced capacity (e.g. a video codec might use fewer reference frames) after freeing some resources.

[ Parent | on HN ]

Re:Concurrency in Rust by Manishearth on Sunday March 27, 2016 @08:09PM (#11372062)

> I do see the need to have a memory allocation approach that can handle OOM gracefully.

Do you find anything wrong with inserting an allocator that panics on OOM (IIRC the default one aborts on OOM) and using `std::panic::recover` to catch the panic? This is the same as throwing and catching an exception. Note that `recover()` is designed to be exception safe by default.

(There soon will be a way to make std heap APIs like box and vec use Result, which might be neater)

[ Parent | on HN ]

Re:Concurrency in Rust by nitrogen on Monday March 28, 2016 @02:14AM (#11372974)

I don't myself, no, but I haven't dived into Rust yet. I'm assuming that recovery can happen at a point where data can still be saved.

[ Parent | on HN ]

Re:Concurrency in Rust by Manishearth on Monday March 28, 2016 @10:58AM (#11374606)

Yeah.

[ Parent | on HN ]