[bennettnate5]

It can also be an issue if you want to wrap any API that requires fixed memory locations for objects (such as POSIX semaphores). It's UB to call a POSIX semaphore from any other memory location than where it was initialized, so making a `Semaphore::new()` API is just asking for trouble. You can deal with it by `Box`ing the semaphore, but then you can't construct the semaphore in a shared memory segment (one of the stronger use cases for process-shared semaphores).

I have a hunch this is why there's no Semaphore implementation in the Rust standard library, though it could be due to fundamental inconsistencies in semaphore APIs across OSs as well ¯\_(ツ)_/¯

[masklinn]

No, Rust doesn't have semaphores in the stdlib[0] because it was not clear what precise semantics should be supported, or what purpose they would serve since by definition they can't mitigate exclusive and thus write access to a resource and mitigating access to code isn't much of a rust convention. And nobody has really championed their addition since.

Furthermore, they still present a fair amount of design challenges in the specific context of Rust: https://neosmart.net/blog/implementing-truly-safe-semaphores...

[0] technically they were there, added in 0.4, never stabilised, deprecated in 1.7, and removed in 1.8