Tracking issue for sync::Semaphore

[alexcrichton]

This is a tracking issue for the unstable semaphore feature of the standard library.

• Should we have this kind of semaphore?
• Should we allow negative counts?
• Should there be an RAII guard for a "resource"?

Decision!

[alexcrichton]

🔔 This issue is now entering its final comment period for deprecation 🔔

If this is used widely, however, we can reconsider!

[aturon]

The long-term vision of concurrency support within std is a bit unclear. The deprecation here reflects a general desire to stick to binding system primitives (as we do with locks). For now, user-space synchronization can live out of tree. (Under this rubric, channels don't really belong either, and in hindsight that would probably have been a reasonable call.)

All that said, in the long run I believe that it's important for Rust to have some official user-space concurrency constructs. This could be a rust-lang crate, or eventually land in std.

[fritzsche]

Was looking for names Semaphore for Intra-Process synchronization like in your repo:
http://alexcrichton.com/ipc-rs/ipc/struct.Semaphore.html
This seems to be just a counter protected by a Mutex?

[sfackler]

@fritzsche a semaphore is a standard synchronization primitive: https://en.wikipedia.org/wiki/Semaphore_(programming)

[alexcrichton]

@fritzsche yeah that repo is for OS semaphores which are normally some form of IPC as well, but as @sfackler mentioned a semaphore is also a synchronization primitive.

This is also partly why I'd like to deprecate for now to avoid confusion about what it is.

[alexcrichton]

The libs team discussed this in triage yesterday and the decision was to deprecate