sync: Move underneath libstd #14746

alexcrichton · 2014-06-08T09:15:05Z

This commit is the final step in the libstd facade, #13851. The purpose of this
commit is to move libsync underneath the standard library, behind the facade.
This will allow core primitives like channels, queues, and atomics to all live
in the same location.

There were a few notable changes and a few breaking changes as part of this
movement:

The Vec and String types are reexported at the top level of libcollections
The unreachable!() macro was copied to libcore
The std::rt::thread module was moved to librustrt, but it is still
reexported at the same location.
The std::comm module was moved to libsync
The sync::comm module was moved under sync::comm, and renamed to duplex.
It is now a private module with types/functions being reexported under
sync::comm. This is a breaking change for any existing users of duplex
streams.
All concurrent queues/deques were moved directly under libsync. They are also
all marked with #![experimental] for now if they are public.
The task_pool and future modules no longer live in libsync, but rather
live under std::sync. They will forever live at this location, but they may
move to libsync if the std::task module moves as well.

[breaking-change]

huonw · 2014-06-08T09:23:42Z

src/libsync/deque.rs

@@ -148,7 +145,7 @@ impl<T: Send> BufferPool<T> {
    /// Allocates a new buffer pool which in turn can be used to allocate new
    /// deques.
    pub fn new() -> BufferPool<T> {
-        BufferPool { pool: Arc::new(Exclusive::new(vec!())) }
+        BufferPool { pool: Arc::new(Exclusive::new(Vec::new())) }


Why this change?

Currently the vec! macro is only exported from libstd, not from libcollections.

huonw · 2014-06-08T09:29:12Z

Travis failed.

I wonder if we need a way to "deprecate" the use of these subcrates of std to guide people to the std:: version. I imagine many users of a direct extern crate sync will not need to be changed after this lands, meaning they'll hang around for a (long) while.

brson · 2014-06-08T22:53:24Z

I'm curious to know what you consider the criteria for concurrent types to live in std. I hope that more advanced future concurrent types might still be in their own crates outside of std; that these types are considered the 'building blocks' or those with runtime dependencies.

brson · 2014-06-08T22:53:56Z

Also, I agree w/ huon about the unfortunate rt dep. Obviously a lot of concurrent types need it, but atomics at least would be nice to have in core (or somewhere not dependent on rt).

sfackler · 2014-06-09T00:23:49Z

We could double-reexport atomics (core -> sync and core -> std)

alexcrichton · 2014-06-09T00:30:31Z

I wonder if we need a way to "deprecate" the use of these subcrates of std to guide people to the std:: version

I worry about this as well.

@aturon is working on stability levels right now, and I plan on marking libsync as #[experimental] or #[unstable], while the reexported contents will be stable. That will in theory issue warnings when you use a path through libsync, but not through libstd.

I imagine many users of a direct extern crate sync will not need to be changed after this lands

Indeed, I changed all of ours only out of preference, not out of necessity.

I'm curious to know what you consider the criteria for concurrent types to live in std.

I want to only expose std::comm and sync::lock. I want all other primitives to live elsewhere, while this crate will have only the very core primitives. I have preserved the visibility of our concurrent queues to preserve backwards compatibility for now. I would prefer to make these all private modules for now.

As an example, I would like futures and task pools to live outside of libstd. I have left them in libsync and libstd for backwards compatibility for now. Also I wanted to keep the diff count down.

Also, I agree w/ huon about the unfortunate rt dep. Obviously a lot of concurrent types need it, but atomics at least would be nice to have in core (or somewhere not dependent on rt).

I'm a little confused by this, core::atomics exists, and it is impossible for any of these primitives to be written without depending on librustrt. The primitives are fundamentally written with the ability to deschedule and reschedule a task.

The AtomicOption type can in theory live in liballoc, but other than that I believe everything must depend on librustrt.

We could double-reexport atomics (core -> sync and core -> std)

This is exactly what is currently happening.

Travis failed.

Indeed! (review always welcome, however!)

This commit is the final step in the libstd facade, rust-lang#13851. The purpose of this commit is to move libsync underneath the standard library, behind the facade. This will allow core primitives like channels, queues, and atomics to all live in the same location. There were a few notable changes and a few breaking changes as part of this movement: * The `Vec` and `String` types are reexported at the top level of libcollections * The `unreachable!()` macro was copied to libcore * The `std::rt::thread` module was moved to librustrt, but it is still reexported at the same location. * The `std::comm` module was moved to libsync * The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`. It is now a private module with types/functions being reexported under `sync::comm`. This is a breaking change for any existing users of duplex streams. * All concurrent queues/deques were moved directly under libsync. They are also all marked with #![experimental] for now if they are public. * The `task_pool` and `future` modules no longer live in libsync, but rather live under `std::sync`. They will forever live at this location, but they may move to libsync if the `std::task` module moves as well. [breaking-change]

This commit is the final step in the libstd facade, #13851. The purpose of this commit is to move libsync underneath the standard library, behind the facade. This will allow core primitives like channels, queues, and atomics to all live in the same location. There were a few notable changes and a few breaking changes as part of this movement: * The `Vec` and `String` types are reexported at the top level of libcollections * The `unreachable!()` macro was copied to libcore * The `std::rt::thread` module was moved to librustrt, but it is still reexported at the same location. * The `std::comm` module was moved to libsync * The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`. It is now a private module with types/functions being reexported under `sync::comm`. This is a breaking change for any existing users of duplex streams. * All concurrent queues/deques were moved directly under libsync. They are also all marked with #![experimental] for now if they are public. * The `task_pool` and `future` modules no longer live in libsync, but rather live under `std::sync`. They will forever live at this location, but they may move to libsync if the `std::task` module moves as well. [breaking-change]

…=Veykril Parse associated return type bounds This PR implements parser support for associated return type bounds: `T: Foo<bar(): Send>`. This PR does not implement associated return types (`T::bar(): Send`) because it's not implemented even in rustc, and also removes `(..)`-style return type notation because it has been removed in rust-lang#110203 (effectively reverting rust-lang#14465). I don't plan to proactively follow this unstable feature unless an RFC is accepted and my main motivation here is to remove no-longer-valid syntax `(..)` from our parser, nevertheless adding minimal parser support so anyone interested (as can be seen in rust-lang#14465) can experiment it without rust-analyzer's syntax errors.

brson mentioned this pull request Jun 8, 2014

Make std a facade #13851

Closed

9 tasks

huonw reviewed Jun 8, 2014
View reviewed changes

bors closed this Jun 11, 2014

alexcrichton deleted the libsync branch June 11, 2014 20:55

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

sync: Move underneath libstd #14746

sync: Move underneath libstd #14746

alexcrichton commented Jun 8, 2014

huonw Jun 8, 2014

alexcrichton Jun 8, 2014

huonw commented Jun 8, 2014

brson commented Jun 8, 2014

brson commented Jun 8, 2014

sfackler commented Jun 9, 2014

alexcrichton commented Jun 9, 2014

sync: Move underneath libstd #14746

sync: Move underneath libstd #14746

Conversation

alexcrichton commented Jun 8, 2014

huonw Jun 8, 2014

Choose a reason for hiding this comment

alexcrichton Jun 8, 2014

Choose a reason for hiding this comment

huonw commented Jun 8, 2014

brson commented Jun 8, 2014

brson commented Jun 8, 2014

sfackler commented Jun 9, 2014

alexcrichton commented Jun 9, 2014