Skip to content

RFC: Task spawn options interface #2954

Closed
@bblum

Description

@bblum

A couple weeks ago we discussed being able to 'chain' task spawn options, which would be much more fun to write than the current builder interface.

I envision:

fn unlinked() -> builder { ... }
fn notify_chan() -> builder { ... }
fn spawn() { ... }

impl for builder {
    fn unlinked() -> builder {
        { link: false with builder }
    }
    fn notify_chan(chan) -> builder 
    ...
    fn spawn() ...
}

With the functions at the top level returning a default set. Then you'll never need to type "builder" - all of these will be valid:

do task::spawn { ... }
do task::unlinked().notify_chan(c).spawn { ... }
do task::notify_chan(c).unlinked().spawn { ... }
let t = task::unlinked();
do t.spawn { ... }
do t.notify_chan(c).spawn { ... }

One problem is noncopyability of certain things that might get put in builder - like wrappers and notify ports (or future stuff...? not entirely clear on that).

Move mode on self can solve that; until then, we could perhaps make it a runtime error by doing the standard option dance. (When move mode on self appears, we can make it a build error without changing the interface.)

type builder = ~mut option<{...record...}>
impl for builder {
    fn set_noncopyable_thing() -> builder {
        let mut result = none;
        result <-> *self;
    }
}

An attempt to use a builder with none in it would fail at runtime.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-enhancementCategory: An issue proposing an enhancement or a PR with one.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions