issue 42: move yield and join into stdlib

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

issue 42: move yield and join into stdlib

Graham Fawcett
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.

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();
+}

join() seems to work; I don't know how to test yield().

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?

Best,
Graham

Reply | Threaded
Open this post in threaded view
|

issue 42: move yield and join into stdlib

Graydon Hoare
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 :)

> 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.

> join() seems to work; I don't know how to test yield().

There are a couple testcases (test/run-pass/yield*.rs) but they don't
definitively test working / non-working-ness of the feature. Really it's
... *almost* irrelevant as a call: we inject time-based preemption
points at loop edges and function calls anyways, and deschedule anything
blocked on I/O, do it really only exists if you're interested in
"smoothing" execution-interleaving in an unusual context (without
adjusting the time-slice). I'm not sure it'll be easy to test in any case.

> 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.

-Graydon

Reply | Threaded
Open this post in threaded view
|

issue 42: move yield and join into stdlib

Graham Fawcett
Hi Graydon,

On Thu, Dec 2, 2010 at 4:54 PM, Graydon Hoare <graydon at 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

Reply | Threaded
Open this post in threaded view
|

issue 42: move yield and join into stdlib

Patrick Walton
On 12/3/10 6:27 AM, Graham Fawcett wrote:
> 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. :)

That typically indicates that rustc couldn't find the LLVM library. (We
need better error reporting there.) It has to be called
libLLVM2.8svn.{so,dll,dylib} and exist somewhere in the current
LD_LIBRARY_PATH (or equivalent on your platform).

Patrick

Reply | Threaded
Open this post in threaded view
|

issue 42: move yield and join into stdlib

Graham Fawcett
On Fri, Dec 3, 2010 at 11:02 AM, Patrick Walton <pwalton at mozilla.com> wrote:

> On 12/3/10 6:27 AM, Graham Fawcett wrote:
>>
>> 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. :)
>
> That typically indicates that rustc couldn't find the LLVM library. (We need
> better error reporting there.) It has to be called
> libLLVM2.8svn.{so,dll,dylib} and exist somewhere in the current
> LD_LIBRARY_PATH (or equivalent on your platform).

D'oh, thanks, I had moved my LLVM installation without reconfiguring.
The memory_region error is no more.

Graham

>
> Patrick
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>