----- Original Message -----
> From: "Graydon Hoare" <[email protected]>
> To: [email protected]
> Sent: Wednesday, May 25, 2011 2:00:19 PM
> Subject: Re: [rust-dev] threads, tasks, scheduling, migrating, failing
>
> On 11-05-25 11:39 AM, Rafael Avila de Espindola wrote:
>
> > Look at the cost we are proposing to
> > get something a bit better: every loop will have a check to know if
> > it
> > should yield or not. Is this really worth it? What is basically
> > doing is
> > trying to give task a similar semantics to what threads already
> > have.
> 
> Yes. And every function call has a check to see if it has to grow the
> stack. We can plausibly collapse these two costs into one in some
> cases.
> In cases where we can't, and it's a performance bottleneck, we can
> offer
> some unsafe variant; but you're assuming a particular datapoint
> without
> evidence just as you accuse me of. We don't know it'll be
> prohibitively
> slow any more than we know bounds checking vector accesses is
> prohibitively slow. I'm not ok with this argument.

I'm assuming this yield flag is primarily for timeouts, correct? What other 
ways are there to set the yield flag?

I was reading some about Erlang today and it looks like they way they handle 
timeouts is to let each program run for a certain number of "reductions." If we 
wanted to fix the timeslice at compile time, we could use a similar approach. 
We could simply insert yields every N instructions, and for loops we could say 
"this loop body is 15 instructions, so we need to make sure to yield every N/15 
iterations." It seems like this would make the "yield flag" mostly unnecessary.

I guess the other reason we need a yield flag is to let tasks kill each other. 
Is there a chance we could handle this in the scheduler? I guess it would 
probably amount to doing the yield flag check somewhere else. That said, look 
at it this way makes me think it's probably not any more expensive than vector 
bounds checks.

-Eric
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to