On 05/18/2013 08:31 PM, Ted Horst wrote:
Is there a design document for the new scheduler?
Not a complete one, but the issue tracker covers some things:
https://github.com/mozilla/rust/issues/4419
___
Rust-dev mailing list
Rust-dev@mozilla.org
http
Is there a design document for the new scheduler?
Ted
On 2013-05-18, at 17:27, Brian Anderson wrote:
> The new scheduler is still far from complete, but there is enough in place
> that we can start to get a sense for its performance characteristics. I've
> done a simulation of making message-
On 05/18/2013 03:27 PM, Brian Anderson wrote:
The new scheduler is still far from complete, but there is enough in
place that we can start to get a sense for its performance
characteristics. I've done a simulation of making message-passing
calls into a layout task and have some preliminary numb
On 05/18/2013 04:05 PM, Patrick Walton wrote:
On 5/18/13 3:27 PM, Brian Anderson wrote:
* layout task places the response message payload into the 'oneshot'
buffer send by script.
* layout does an atomic swap with full fence to check the status of the
script task and sees that it is not waiting
On 5/18/13 3:27 PM, Brian Anderson wrote:
* layout task places the response message payload into the 'oneshot'
buffer send by script.
* layout does an atomic swap with full fence to check the status of the
script task and sees that it is not waiting for the response message
(it's in the work queu
On 5/18/13 3:27 PM, Brian Anderson wrote:
The new scheduler is still far from complete, but there is enough in
place that we can start to get a sense for its performance
characteristics. I've done a simulation of making message-passing calls
into a layout task and have some preliminary numbers.
The new scheduler is still far from complete, but there is enough in
place that we can start to get a sense for its performance
characteristics. I've done a simulation of making message-passing calls
into a layout task and have some preliminary numbers.
The new scheduler is a work-stealing sch
On 2013-05-18, at 17:46 , Renato Lenzi wrote:
> I don't understand why this code is bad:
>
> let n1 = int::from_str(line);
> if n1 == 0
>
> compiler complains:
>
> 3.rs:7:12: 7:13 error: mismatched types: expected
> `core::option::Option
> ` but found `` (expected enum core::option::Op
On Sat, May 18, 2013 at 11:57 AM, Corey Richardson wrote:
> ```
> match int::from_str(line) {
> Some(x) => n1 = x,
> None => { /* handle error... */}
> }
> if n1 == 0 {
> ...
> ```
Amend that to:
let n1;
match int::from_str(line) {
Some(x) => n1 = x,
None => { /* handle error...
On Sat, May 18, 2013 at 11:46 AM, Renato Lenzi wrote:
> I don't understand why this code is bad:
>
>let n1 = int::from_str(line);
>if n1 == 0
>
> compiler complains:
>
> 3.rs:7:12: 7:13 error: mismatched types: expected
> `core::option::Option
> ` but found `` (expected enum core::opti
I don't understand why this code is bad:
let n1 = int::from_str(line);
if n1 == 0
compiler complains:
3.rs:7:12: 7:13 error: mismatched types: expected
`core::option::Option
` but found `` (expected enum core::option::Option but found integral
varia
ble)
3.rs:7if n1 == 0
wht's
On Thu, May 16, 2013 at 7:58 PM, Graydon Hoare wrote:
>
> I'm sympathetic to the desire here, as with all attempts to "get
> exceptions right". Sadly I've never really seen it; I don't think anyone
> has really worked out the "right" way to work with catchable-exceptions in
> a language.
>
> -Gra
12 matches
Mail list logo
