Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is somewhat similar to the idea of linear futures where a type system is used to ensure that each future is used exactly once. This still allows the kind of structure suggested in this article but with slightly different constraints. One issue is that linear futures don’t really allow for a select-like operation which takes some futures for a value of type T and returns a single future for a clue of type T that becomes determined to the same value as on of the input futures (roughly the one that finishes first but slightly undefined).

A question for this proposal (or linear futures): how do you implement a time out? That is, a future that either becomes determined to some input future, or some error value if the input takes too long.

The other big issue with joining control flow in async systems is error handling: when you join two threads, you can get two successes, one error, or two errors. When you select between two threads, you can get a success and, later, an error. Typically you want to pass the first error on eagerly. But where to? Do you pass it to something depending on the result of the future, or something from the dynamic scope when the future was created, or something else? And what happens with the second error? It might be bad to ignore it but it might be too late to care also. And the place where you might want to pass the error could be long gone by now.



I think the article handles both cases (timeouts and the first error) by cancelling the other running async operations as quickly as it can.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: