Introduce `join_context` which tells whether jobs were stolen

[cuviper]

This removes the need for tracking thread-id or hacky TLS variables in
the adaptive splitter. Instead, with join_context the parallel
iterator internals are directly informed whether a job is executing on
its original thread or stolen elsewhere.

Note that this is insta-stable since we want to use it ourselves. We
could hide docs and/or mark it deprecated to approach stability a little
differently than the usual "unstable" feature.

[leodasvacas]

Should the name be changed considering that unpark got renamed to notify in futures?

[cuviper]

I think the places you'd use this are distinct enough from futures, but I'm open to other names.

[nikomatsakis]

I wonder if we should design this API in a more open-ended way. That is, right now it supplies a simple bool. But maybe it should supply a struct with methods, so that we can add additional information in the future.

[nikomatsakis]

As an example, I think it'd potentially be useful to tell closure B whether it was stolen or not (irrespective of whether we wound up jumping into the Rayon thread-pool). Right now, closure B can't tell the difference between the two.

[nikomatsakis]

Apart from that nit, though, I think this looks pretty nice, and I'm inclined to say I like it better than the current hack of testing which thread you are on. It feels cleaner to me to be told, particularly since it doesn't require a lot of work on our part to track that information.

[cuviper]

Rebased and renamed to join_context with an opaque FnContext struct, still just a single bool for now. I didn't call it just JoinContext because I thought it might be a useful addition to stuff like spawn too. Alternate name suggestions are welcome.

I think that looks ok? Some gains, some losses -- seem like noise.

[nikomatsakis]

Hmm, I think I expected &FnContext, but I guess there's not a ton of reason for that. If we wanted to maximally future-proof, I think we would pass a FnContext<'a>, where 'a is (for the moment) just a phantom-lifetime. This would give us the ability to have FnContext grow some amount of by-reference data later.

e.g.

struct FnContext<'a> {
    migrated: bool,
    dummy: PhantomData<&'a ()>,
}

[cuviper]

Then its Default seems weird to me, which is used by the bridge functions in their starting state. Should we allow arbitrary FnContext<'a> in that case, or just FnContext<'static>?

Perhaps we should also force this !Send and !Sync if we think it might reference local state.

[nikomatsakis]

Hmm I think I didn't notice that it supports Default. Maybe it's overkill to worry about this stuff anyway.

[cuviper]

Rebased.

[nikomatsakis]

Do we really want this to support default? That means anybody can make one...?

[cuviper]

I thought I needed a way for the iterator bridge functions to create one -- which is as good as "anybody" as far as crate privacy goes -- but I just modified those to extract the migrated bool to pass around instead.

[nikomatsakis]

bors r+

[bors]

Build succeeded

• continuous-integration/appveyor/branch
• continuous-integration/travis-ci/push