Hi Graydon,
On Thu, Dec 2, 2010 at 4:54 PM, Graydon Hoare <gray...@mozilla.com> wrote:
> On 10-12-02 01:19 PM, Graham Fawcett wrote:
>>
>> Hi folks,
>>
>> While I'm waiting for something at $WORK to compile, I thought I'd
>> take a crack at easy issue #42, moving yield and join into the
>> standard library.
>
> Great! Thanks. I guess it's pretty easy to do now :)
Well, it was a long compile (and I'm not quite done with #42 yet). :)
>> After removing the yield and join keywords from the front/middle ends,
>> is it enough to just add this to std._task:
>>
>> native "rust" mod rustrt {
>> fn task_sleep(uint time_in_us);
>> + fn upcall_join(task t);
>> + fn upcall_yield();
>> }
>>
>> +fn join(task t) {
>> + ret rustrt.upcall_join(t);
>> +}
>> +
>> +fn yield() {
>> + ret rustrt.upcall_yield();
>> +}
>
> Might well be enough, yeah. You'll also want to adjust the testcases that
> twiddle these keywords.
Right, I've gone through the test cases too. I notice that some of the
tests don't run when I "make check." E.g., it runs task-comm-N.rs for
N in {0,1,4,5,6,7,11,13} but not the others. Is this normal?
It also tries to perform "compile [rustc]" tests, which fail right
away:
compile [rustc]: test/run-pass/arith-0.rs
rt: fatal, 'leaked memory in rust main loop (52 objects)' failed,
rt/memory_region.cpp:99 52 objects
...which I assume is okay? I don't think I broke rustc. :)
>> I see that nothing else in the stdlib calls an upcall_ function; is
>> this bad form? Should I add task_yield and task_join to
>> rust_builtin.cpp instead, the way task_sleep is handled?
>
> Yeah, probably. The term "upcall" is sort of vestigial from an earlier
> iteration of the compiler <-> runtime boundary when we weren't using direct
> stack-switching calls. Upcalls were structured more like syscalls in C,
> packing arguments into a structure and entering a generic
> suspend-me-and-dispatch-upcall routine. That's long gone.
>
> What we currently reserve the (dubious) "upcall" term for is "native calls
> generated by the compiler". So at present, for symmetry with this rule,
> adding task_* functions to rust_builtin is better. But only because it is
> sort of uniform and makes the job of future reorganization of naming more
> obvious.
Thanks, that clears things up a lot. OK, I'll add the task_*
functions.
I started a fork on github. When I'm ready, do you want a pull-request?
Best,
Graham
>
> -Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
