*Request unsafe in presence of memory leaks about rsmpi HOT 3 CLOSED

Good catch, thank you.

Although the scope-based mechanism does lead to somewhat convoluted code, I think it is the more general solution. This way the non-blocking operations can still be used on borrowed buffers and thus the same buffer can be used in more than one send operation, or can be involved in a send operation and read from at the same time. Using the existing guard based design with owned buffers would likely require Arq and friends to make this work, not sure one could get the C code that actually fulfils the request to uphold the exclusivity constraints though.

I still have to think some more about whether it is possible to carry over the freedom of when exactly one wants to wait for a specific request (or even cancel it) into the scope based design. Only being able to wait for all operations initiated within a scope at its exit seems like a restriction. But then again, this might be what is necessary to actually provide a safe API in the Rust sense of the word.

Currently, I do not have huge amounts of free time on my hands, would you be willing to do some work on this issue?

from rsmpi.

Can't promise I'll have time to work on it either, but I'll think about it.

from rsmpi.

Should be fixed by #18.

from rsmpi.