On 11/14/13 6:45 AM, Patrick Walton wrote:
If we need to split out the Rust standard library into a core set of
interfaces that remain the same across different implementations, then I
think it would be much more productive to talk about doing that. I've
reviewed rust-core and I don't really see any fundamental differences
that prevent compatibility with the standard library--in fact, I'd
really like to try to just merge them: pulling in the I/O as the "native
I/O" module, eliminating redundant traits from libstd, eliminating
conditions, taking whichever algorithms are faster, and so on. We can
find and shake out bugs as we go.
To be more specific, here's how I propose to move forward.
1. Finish fleshing out the native I/O in libstd to achieve parity with
the uv-based I/O.
2. Provide pthread-based implementations of `task::spawn`.
3. Provide native TLS with a matching API to the task-local storage API.
4. Figure out what to do about ports and channels and failure in 1:1
scheduling.
At this point we will have a task story for 1:1 scheduling that mirrors
the M:N scheduling. We will then have a solid basis to decide what the
defaults should be on each platform. If we decide that 1:1 scheduling is
the best fit for all platforms, we can then consider dumping the M:N
scheduling.
At the same time, I would like to suggest that rust-core track the APIs
of libstd and file bugs/PRs to get APIs changed if there are problems,
to avoid fragmenting downstream libraries.
I welcome discussion on this strategy and hope that it's acceptable to
everyone.
Patrick
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
