On 4/27/13 4:06 AM, David Bruant wrote:
I believe too this is doomed to happen. Firefox is under a huge struggle to remove as much as sync IO code as possible as part of the Snappy effort [1].
This is a completely misleading comparison. Firefox's sync I/O *blocks the entire main thread of the browser*, freezing up the UI in the process. That's why Firefox is removing it. Firefox doesn't have lightweight green threads. And Servo doesn't even have a "main thread".
Tasks provide something easier to use than threads, so a browser in Rust can make things snappier by moving things to tasks, but allocation, de-allocating and scheduling have a cost.
There is a plan to cache aggressively, to avoid allocation and deallocation of stacks. Scheduling is very quick, just a context switch in userspace.
Still, one stack per I/O operation has a bad smell to it. Being forced to create a new task (even if "only" 2k) because the 49000 previous ones are sitting idle doesn't sound right. Not contacting the remote resource (disk, network) would be worse. To do efficient IO, there got to be a cheap way to start an IO and wait for it. Creating a task, doesn't sound cheap enough to work at scale.
I don't see any reason why not; the overhead of one userland context switch seems minuscule to me compared to the overhead of doing the I/O. Have you done benchmarks?
I'd like to encourage everyone reading to take the time to watch [2] (at least 10-15mins starting where I linked to).
If you're going to count allocation and deallocation of stacks against Rust's model, then why not count the allocation and deallocation of the callback closures and associated environments in node.js' model? It is *not* the case that node.js I/O allocation-free, as you're implying.
If you're carrying around state per I/O request, and you have an unbounded number of I/O requests that can be in flight, you must incur an allocation to store that state. Whether that's part of a callback or part of a task's stack, it has to happen.
Patrick _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
