std: Second pass stabilization of sync

[alexcrichton]

This pass performs a second pass of stabilization through the std::sync
module, avoiding modules/types that are being handled in other PRs (e.g.
mutexes, rwlocks, condvars, and channels).

The following items are now stable

• sync::atomic
• sync::atomic::ATOMIC_BOOL_INIT (was INIT_ATOMIC_BOOL)
• sync::atomic::ATOMIC_INT_INIT (was INIT_ATOMIC_INT)
• sync::atomic::ATOMIC_UINT_INIT (was INIT_ATOMIC_UINT)
• sync::Once
• sync::ONCE_INIT
• sync::Once::call_once (was doit)
  • C == pthread_once(..)
  • Boost == call_once(..)
  • Windows == InitOnceExecuteOnce
• sync::Barrier
• sync::Barrier::new
• sync::Barrier::wait (now returns a bool)
• sync::Semaphore::new
• sync::Semaphore::acquire
• sync::Semaphore::release

The following items remain unstable

• sync::SemaphoreGuard
• sync::Semaphore::access - it's unclear how this relates to the poisoning
  story of mutexes.
• sync::TaskPool - the semantics of a failing task and whether a thread is
  re-attached to a thread pool are somewhat unclear, and the
  utility of this type in sync is question with respect to
  the jobs of other primitives. This type will likely become
  stable or move out of the standard library over time.
• sync::Future - futures as-is have yet to be deeply re-evaluated with the
  recent core changes to Rust's synchronization story, and will
  likely become stable in the future but are unstable until
  that time comes.

[breaking-change]

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @aturon

[alexcrichton]

cc @steveklabnik, the guide mentions futures and this may affect that

[aturon]

Overall this looks good, but I'm a bit uncomfortable stabilizing any of the methods of Semaphore until the panic/poison story is more clear. We might want acquire to yield a result, for example.

A smaller nit is the bool return type for wait on barriers; conventions demand it be an enum.

[alexcrichton]

Rebased, semaphores are now #[unstable], and barriers now return a BarrierWaitResult with one is_leader method.

re-r? @aturon

[flaper87]

I remember adding these implementations because some tests needed them. If you are removing them from std::sys::unix, could you please clean up windows as well?

[alexcrichton]

Hm I think I was overzealous here, UnixStream above didn't need the impls but due to CString these are needed.

[flaper87]

I think I'm missing something but, why shouldn't UnixStream be Send and Sync ?

[flaper87]

@alexcrichton

Mmh why can't UnixStream be Send and Sync as well? It owns an Arc, which already implements these traits. The same applies for the other types in std::sys::unix

Am I missing something?

Also, it'd be nice to use this change to make both, Unix and windows, implementations consistent.

[alexcrichton]

UnixStream is automatically inferred to be Send and Sync, it doesn't need the extra unsafe impl blocks (or so I am led to believe). I also believe that the same applies for AcceptorInner.

The windows implementations need manual unsafe impl blocks due to containing libc::HANDLE which is just a raw pointer which is itself not Send or Sync.

[flaper87]

@alexcrichton yup, it's inferred to be Send and Sync but I preferred there to be explicit implementations. However, after putting some extra thought on this, I think it's better not to have explicit implementations when they are no needed, this will protect us from mistakenly breaking types guarantees without noticing. That is to say, if a change to UnixStream makes it NoSend, we'll get errors.

re-windows: fair enough. Though, I wonder if we should implement Send and Sync for Inner and Event instead of implementing them for UnixStream, AcceptorState etc. That'd remove some of the explicit implementations of these traits. It'll also make the unix and windows implementations more consistent and finally, it'll prevent us from making some dumb mistakes.

Otherwise, LGTM.

[flaper87]

@alexcrichton not sure if you read my last comment. I'm wondering what you think about the last thing I said about Window's implementations. I think it's worth it.

[alexcrichton]

Oh sorry, forgot to respond! I'd totally be in favor of implementing those traits for those types, it's precisely what we should be doing! As internal implementation details though, I was hoping to land this before giving it another go at the implementation level :)