[experiment] remove CURRENT_TASK thread-local variable

[dwrensha]

CURRENT_TASK was introduced in #77, a change that bundled the removal of the schedule() method together with the removal of the task parameter to poll(). There has been some discussion, e.g. in #129, about whether the latter removal has been a net win. My feeling is that is has not, and this pull request represents my attempt to see what would be involved in bringing back explicitly-passed tasks.

I have not yet figured out a way to get task-local storage working with this approach, so at the moment this pull request removes task_local!(). I'm interested in hearing about any ideas for how we could continue to support task-local storage, or how we might design something that fills the same need.

[dwrensha]

Hm. Another issue is that Task depends on ::std::sync::Arc, and therefore will not be available in no_std environments.

[Diggsey]

For efficient task-local storage, you might need to have a LocalTask/RemoteTask pair like in tokio, and only allow access to task-local storage through a LocalTask.

This could be implemented as a RefCell<AnyMap> on the LocalTask. Only the RemoteTask would need Arc to be implemented.

[Diggsey]

On second thoughts, I think the important distinction is not between Local/Remote: it's actually between whether we're in the task, or simply referring to the task.

Instead of introducing LocalTask/RemoteTask types, add a new type, TaskHandle through which a task can be unparked. Task would be neither Sync nor Clone, and with_unpark_event would invoke a closure with a &Task scoped to the lifetime of that closure.

A &Task can at any time be downgraded to a TaskHandle, which can be freely cloned and stored, while task-local storage can only be accessed through a &Task.

[carllerche]

The discussion around the concepts introduced in the PR are being discussed in #129.

[alexcrichton]

Note that with #436 this crate is now compatible with no_std entirely (including the task system) with only a requirement you call the init function with thread-local-like semantics. In that sense we still rely on a thread-local somewhere but it may impact this somewhat as well.

[alexcrichton]

Ok at this point this is a pretty old PR without a lot of recent activity, so I'm going to close this. Discussion can of course continue on #129 though!