On Wed, Nov 13, 2013 at 1:32 PM, Alex Crichton <a...@crichton.co> wrote: > The situation may not be as dire as you think. The runtime is still in a state > of flux, and don't forget that in one summer the entire runtime was rewritten > in > rust and was entirely redesigned. I personally still think that M:N is a > viable > model for various applications, and it seems especially unfortunate to just > remove everything because it's not tailored for all use cases. > > Rust made an explicit design decision early on to pursue lightweight/green > tasks, and it was made with the understanding that there were drawbacks to the > strategy. Using libuv as a backend for driving I/O was also an explicit > decision > with known drawbacks. > > That being said, I do not believe that all is lost. I don't believe that the > rust standard library as-is today can support *every* use case, but it's > getting > to a point where it can get pretty close. In the recent redesign of the I/O > implementation, all I/O was abstracted behind trait objects that are > synchronous > in their interface. This I/O interface is all implemented in librustuv by > talking to the rust scheduler under the hood. Additionally, in pull #10457, > I'm > starting to add support for a native implementation of this I/O interface. The > great boon of this strategy is that all std::io primitives have no idea if > their > underlying interface is native and blocking or libuv and asynchronous. The > exact > same rust code works for one as it does for the other. > > I personally don't see why the same strategy shouldn't work for the task model > as well. When you link a program to the librustuv crate, then you're choosing > to > have a runtime with M:N scheduling and asynchronous I/O. Perhaps, though, if > you > didn't link to librustuv, you would get 1:1 scheduling with blocking I/O. You > would still have all the benefits of the standard library's communication > primitives, spawning primitives, I/O, task-local-storage etc. The only > difference is that everything would be powered by OS-level threads instead of > rust-level green tasks. > > I would very much like to see a standard library which supports this > abstraction, and I believe that it is very realistically possible. Right now > we > have an EventLoop interface which defines interacting with I/O that is the > abstraction between asynchronous I/O and blocking I/O. This sounds like > we need a more formalized Scheduler interface which abstracts M:N scheduling > vs > 1:1 scheduling. > > The main goal of all of this would be to allow the same exact rust code to > work > in both M:N and 1:1 environments. This ability would allow authors to > specialize > their code for their task at-hand. Those writing web servers would be sure to > link to librustuv, but those writing command-line utilities would simply just > omit librustuv. Additionally, as a library author, I don't really care which > implementation you're using. I can write a mysql database driver and then you > as > a consumer of my library decided whether my network calls are blocking or not. > > This is a fairly new concept to me (I haven't thought much about it before), > but > this sounds like it may be the right way forward to addressing your concerns > without compromising too much existing functionality. There would certainly be > plenty of work to do in this realm, and I'm not sure if this goal would block > the 1.0 milestone or not. Ideally, this would be a completely > backwards-compatible change, but there would perhaps be unintended > consequences. > As always, this would need plenty of discussion to see whether this is even a > reasonable strategy to take.
The same Rust code won't work with both 1:1 threading and M:N threading though. It's nearly impossible to expose safe bindings to a library like NSS with a heavy dependency on thread-local storage. With task pinning, the libraries could pin the task to the thread they were initialized on, but the interface is going to be much lower level than C. It will need a context object with all the functions as methods for the application to shove into task-local storage. I don't think it's possible to build completely lossless abstractions over the differences in TLS and I/O. A library supporting both will have an inferior API to a library with only 1:1 threading. There's an expectation that a language will work with a profiler like callgrind or provide these tools itself. Go comes with an implementation of CPU/memory profiling and analysis of M:N threading. Where are Rust's versions of these tools? The robust, proven solution is 1:1 threading and many operating systems used M:N threading before dropping it due to the significant drawbacks. The move to more expensive fair CPU scheduling didn't happen by historical accident. An M:N threading implementation is nothing but a performance optimization for the HPC and socket server use cases to avoid context switches. I'm not willing to make compromises in semantics or performance for other use cases to support this. I want Rust to be a viable replacement for C, C++, Java, C# and other languages but I don't see it happening with the standard library, so I'll just put my full effort behind developing an alternative. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
