About datapoits. No, I don't have them. It is too early for that.
We don't need tasks right now. C, C++ and Java have come a *long*
way without them and they have a significant market share.
Yes, they came a long way, until parallelism finally happened.
Writing efficient and safe parallel code in C/C++/Java is simply not
feasible. You are trying to built a fighter jet out of matchsticks.
Insistently, the F35 is another good example of something built with c++.
The kernel of the 3 systems we are targeting is written in C or C++. It
is hard to imagine us being more scalable than the kernel.
Having high parallelism in the hardware is a good argument for threads!
Implementing tasks makes sense when the programmer wants to abstract
more things happening at the same time than really are.
If my new machine has 512 register sets (HT), I need 512 threads to use
them (unless the CPU knows what a rust task is :-) ).
The important point is that once we have web servers, GUI toolkits,
image decoders, audio APIs, etc available in rust, we will have
data points. It might be that, like what happened to java, using
1:1 is the best. If not, we can then implement M:N as an
optimization.
We will not be able to build a system as complex as a web server in a
parallel and dependable way if we have to use bare metal abstractions
like pthreads and signals and shared memory and what not. That simply
won't happen. We have proof of that (Gecko is almost exclusively
single threaded, not by choice, but simply because the complexity
cost is unbearable to change that).
So, as Graydon mentioned, we *can* build a system with a 1:1 mapping and
the same semantics. Not a single drop in safety or anything.
What is the worst thing that can happen? One year from new we decide
that having 10^6 tasks is really the feature that we must have we add
that while keeping the same interface.
Andreas
Cheers,
Rafael
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
