[swift-evolution] [Concurrency] Fixing race conditions in async/await example
howard.lovatt at gmail.com
Sat Aug 26 00:27:23 CDT 2017
My argument goes like this:
1. You don't need async/await to write a powerful future type; you can
use the underlying threads just as well, i.e. future with async/await is no
better than future without.
2. Since future is more powerful, thread control, cancel, and timeout,
people should be encouraged to use this; instead because async/await are
language features they will be presumed, incorrectly, to be the best way,
consequently people will get into trouble with deadlocks because they don't
3. async/await will require some engineering work and will at best make a
mild syntax improvement and at worst lead to deadlocks, therefore they just
Therefore, save some engineering effort and just provide a future library.
To turn the question round another way, in two forms:
1. What can async/wait do that a future can't?
2. How will future be improved if async/await is added?
On 26 August 2017 at 02:23, Joe Groff <jgroff at apple.com> wrote:
> On Aug 25, 2017, at 12:34 AM, Howard Lovatt <howard.lovatt at gmail.com>
> In particular a future that is cancellable is more powerful that the
> proposed async/await.
> It's not more powerful; the features are to some degree disjoint. You can
> build a Future abstraction and then use async/await to sugar code that
> threads computation through futures. Getting back to Jakob's example,
> someone (maybe the Clang importer, maybe Apple's framework developers in an
> overlay) will still need to build infrastructure on top of IBActions and
> other currently ad-hoc signalling mechanisms to integrate them into a more
> expressive coordination framework.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution