Redesign task API

[brson]

It's a bit messy and uncomposable. There are various things we would like to be able to do but can't yet - set min rust stack size, set c stack size, perform operations on schedulers, specify 1:1 thread-to-task scheduling mode, add various hooks to either the spawner or spawnee.

Some unimplemented ideas are in #1721.

See also #595

[nikomatsakis]

I have some thoughts on this. I will try to mock up a prototype and see if they make sense before writing them out here.

[brson]

I know you do and I was hoping you would help :-D

[nikomatsakis]

So, I had this crazy idea involving bind that would allow us to create tasks with all kinds of options in a very flexible way. I tried implementing it and found it was elegant in theory but a horrible mess in practice. Therefore, I was thinking that something simple would work better.

For example, a base task API that takes an options struct along with a unique closure:

enum task = uint;
fn defaults() -> opts;
fn spawn(opts: opts, body: fn~()) -> task;

then we can have a couple of other modules encapsulating common patterns. For example an actor module that creates a task with its own mailbox so that others can send messages to it, or a future module that creates a task that computes a result. I elaborated out those two examples in a blog post so I won't repeat it here.

This isn't so different from what we have now, I guess, just a bit better organized. Is it too simple, or workable?

[nikomatsakis]

Brian and I had a sit-down on this. The end-result was a builder-based API that makes some use of futures. I documented the ideas here:

http://smallcultfollowing.com/babysteps/blog/2012/02/14/using-futures-in-the-task-api/

[brson]

Unsupervise should be an operation parents perform on children, not on themselves.