Change how task::future_result works

[catamorphism]

A FIXME note said "Once linked failure and notification are
// handled in the library, I can imagine implementing this by just
// registering an arbitrary number of task::on_exit handlers and
// sending out messages." The bugs this referred to are closed, so nothing's blocking this.

[bblum]

There isn't presently a mechanism for atexit handlers, which would be required to do it the way the comment suggests. Alternatively the notify_port could just be replaced with a list of notify_ports.

Either way, seems useful to enable multiple tasks futuring on a single task's exit.

[brson]

I think the approach in that comment is obsolete with pipes. Now I prefer changing the task notification to a pipes::OneShot (with a different name), and have a SharedOneShot type, like SharedChan. I'm not sure where Future fits in, but OneShot seems to be the appropriate type for one-time notifications.

[brson]

And of course the callback interface of future_result is very awkward still.

[bblum]

SharedOneShot would kind of defeat the purpose of oneshot pipes. Only one task could receive a message on it; the rest would fail. Oneshots would work with the "list of notify_ports" approach.

Having multiple tasks wait on a single condition is the "condition variable" model (cond-wait/cond-broadcast) -- we have condvars, but they are in libstd. They are just implemented with a list of oneshots, though, so I think having a list of notify_portspipes and making them oneshot makes the most sense.

[bblum]

(re: callback interface) yeah, I wasn't happy with that at all. that was the one thing the builder interface did better.

[brson]

That is not how I was thinking SharedOneShot would work. Maybe that's not the right name, since it isn't the same as SharedChan. I want a shared object that, the first time it is waited on performs the recieve, and subsequent times just looks at the value. Maybe a better composition would be some kind of Mutex<Future<T>> where Future can take a OneShot (Future currently only takes it's own pipe protocol).

[brson]

This is similar to the problem with sharing futures of images in servo. Somebody has to receive the value the first time, then everybody else becomes a reader.

[bblum]

Oh, right, and all other waiting tasks instead wait at the boundary of the MutexARC (which uses pipes internally). Sure. Also has the advantage of not needing to add new machinery and also not needing to call future_result at spawn-time multiple times (instead you can call clone() whenever you want).

[pnkfelix]

Visited for bug-triage, 2012jun24. Comment still exists in libstd/task/mod.rs. (And of course, brian's comment above indicates that he would prefer approach via pipes; I'm guessing until that is done, it is best to leave the comment in place as is, so people can see the dialogue here.)

[huonw]

Triage: still a problem.

[emberian]

The readme is still there. Should this remain, @alexcrichton? Seems... mostly obsolete?

[alexcrichton]

Hm, this doesn't quite make sense to me. The std::task api needs to be scrutinized regardless, but I would personally punt this to stability attributes.

Nominating for removal from the 1.0 milestone because I think that this should be taken care of with stability attributes instead.

[ehsanul]

Is the current alternative to somehow use notify_chan for tasks to monitor each others' failure? I have two tasks, parent and child, which do not communicate with each other, but need some sort of linked failure - if one fails, the other should as well. There is no Chan to propagate failure between the tasks, and it's unclear to me how to do this with the current tasks api.

[pnkfelix]

We're going to leave it as is, on the 1.0 milestone.

[brson]

Nominating for removal from milestone. future_result is sane enough now that it's not the end of the world to be stuck with it forever (it used to require capturing in- and moving back out of a closure).

I still would rather this be a spawn_result method or something, so it doesn't break the builder pattern.

[aturon]

@brson Just a heads-up: I have a patch in progress that revamps the task spawning API along exactly the lines you're suggesting, among other things. (I was waiting for librustrt to land before completing this.)

+1 on milestone removal.

[pnkfelix]

Removing from milestone.

We are trying to systemically review our libraries and mark them with stabilty attributes as appropriate. Leaving as P-backcompat-libs in hopes that it will be caught when all such tagged issues are reviewed.