First off, I’m still catching up with all those (very welcome :-) threads about
concurrency, so bear with me if I’m commenting on topics that have been settled
in the meantime.
> Am 18.08.2017 um 17:13 schrieb Johannes Weiß via swift-evolution
> <swift-evolution@swift.org>:
>
> Hi Chris & swift-evo,
>
> (Given the already lengthy thread I tried to separate my points and keep them
> reasonably short to allow people to skip points they don't care about. I'm
> very happy to expand on the points.)
>
> Thanks very much for writing up your thoughts/proposal, I've been waiting to
> see the official kick-off for the concurrency discussions :).
>
> I) Let's start with the async/await proposal. Personally I think this is the
> right direction for Swift given the reality that we need to interface with
> incredibly large existing code-bases and APIs. Further thoughts:
>
> - ❓ GCD: dispatching onto calling queue, how?
> GCD doesn't actually allow you to dispatch back to the original queue, so I
> find it unclear how you'd achieve that. IMHO the main reason is that
> conceptually at a given time you can be on more than one queue (nested
> q.sync{}/target queues). So which is 'the' current queue?
>
> - ⊥ first class coroutine model => async & throws should be orthogonal
> given that the proposal pitches to be the beginning of a first class
> coroutine model (which I think is great), I think `async` and `throws` do
> need to be two orthogonal concepts. I wouldn't want automatically throwing
> generators in the future ;). Also I think we shouldn't throw spanner in the
> works of people who do like to use Result<E, T> types to hold the errors or
> values. I'd be fine with async(nothrow) or something though.
I, too, would like to keep async & throws orthogonal for these reasons. Even in
the case of async meaning asynchronous or parallel execution I would expect
that throwing is not implied as long as we are not using distributed execution
or making things cancellable. As long as I am on the same machine just
executing something in parallel on another CPU (but within the same runtime)
does not make it failable, does it?
> - what do we do with functions that invoke their closure multiple times? Like
> DispatchIO.read/write.
>
>
> II) the actor model part
>
> - 👯 Erlang runtime and the actor model go hand in hand
> I really like the Erlang actor model but I don't think it can be separated
> from Erlang's runtime. The runtime offers green threads (which allow an actor
> to block without blocking an OS thread) and prevents you from sharing memory
> (which makes it possible to kill any actor at any point and still have a
> reliable system). I don't see these two things happening in Swift. To a
> lesser extend these issues are also present in Scala/Akka, the mitigate some
> of the problems by having Akka Streams. Akka Streams are important to
> establish back-pressure if you have faster producers than consumers. Note
> that we often can't control the producer, they might be on the other side of
> a network connection. So it's often very important to not read the available
> bytes to communicate to the kernel that we can't consumes bytes that fast. If
> we're networking with TCP the kernel can then use the TCP flow-control to
> signal to the other side that they better slow down (or else packets will be
> dropped and then need to be resent later).
>
> - 💥 regarding fatal failure in actors
> in the server world we need to be able to accept hundreds of thousands
> (millions) of connections at the same time. There are quite a few cases where
> these connections are long-lived and paused for most of the the time. So I
> don't really see the value in introducing a 'reliable' actor model where the
> system stops accepting new connections if one actor fatalError'd and then
> 'just' finishes up serving the existing connections. So I believe there are
> only two possible routes: 1) treat it like C/C++ and make sure your code
> doesn't fatalError or the whole process blows up (what we have right now) 2)
> treat it like Erlang and let things die. IMHO Erlang wouldn't be successful
> if actors couldn't just die or couldn't be linked. Linking propagates
> failures to all linked processes. A common thing to do is to 1) spawn a new
> actor 2) link yourself to the newly spawned actor 3) send a message to that
> actor and at some point eventually await a reply message sent by the actor
> spawned earlier. As you mentioned in the writeup it is a problem if the actor
> doesn't actually reply which is why in Erlang you'd link them. The effect is
> that if the actor we spawned dies, any linked actor will die too which will
> the propagate the error to an appropriate place. That allows the programmer
> to control where an error should propagate too. I realise I'm doing a poor
> job in explaining what is best explained by documentation around Erlang:
> supervision [1] and the relationship between what Erlang calls a process
> (read 'actor') and errors [2].
I also think that being able to link processes (i.e. actors) an get reliably
notified of their death is a crucial aspect of Erlang’s success! This is
something that should definitely be part of Swift’s actor model (and extended
to distributed actors when they are tackled in the future).
-Thorsten
>
> - ♨️ OS threads and actors
> as you mention, the actor model only really works if you can spawn lots of
> them, so it's very important to be able to run hundreds of thousands of them
> on a number of OS threads pretty much equal to your number of cores. That's
> only straightforward if there are no (OS thread) blocking operations or at
> least it's really obvious what blocks and what doesn't. And that's not the
> case in Swift today and with GCD you really feel that pain. GCD does spawn
> threads for you and has a rather arbitrary limit of 64 OS threads (by default
> on macOS). That is too many for a very scalable server application but too
> few to just tolerate blocking APIs.
>
>
> [1]:
> http://erlang.org/documentation/doc-4.9.1/doc/design_principles/sup_princ.html
> [2]: http://learnyousomeerlang.com/errors-and-processes
>
> -- Johannes
>
>
>> On 17 Aug 2017, at 11:25 pm, Chris Lattner via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>>
>>> On Aug 17, 2017, at 3:24 PM, Chris Lattner <clatt...@nondot.org> wrote:
>>>
>>> Hi all,
>>>
>>> As Ted mentioned in his email, it is great to finally kick off discussions
>>> for what concurrency should look like in Swift. This will surely be an
>>> epic multi-year journey, but it is more important to find the right design
>>> than to get there fast.
>>>
>>> I’ve been advocating for a specific model involving async/await and actors
>>> for many years now. Handwaving only goes so far, so some folks asked me to
>>> write them down to make the discussion more helpful and concrete. While I
>>> hope these ideas help push the discussion on concurrency forward, this
>>> isn’t in any way meant to cut off other directions: in fact I hope it helps
>>> give proponents of other designs a model to follow: a discussion giving
>>> extensive rationale, combined with the long term story arc to show that the
>>> features fit together.
>>>
>>> Anyway, here is the document, I hope it is useful, and I’d love to hear
>>> comments and suggestions for improvement:
>>> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
>>
>> Oh, also, one relatively short term piece of this model is a proposal for
>> adding an async/await model to Swift (in the form of general coroutine
>> support). Joe Groff and I wrote up a proposal for this, here:
>> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619
>>
>> and I have a PR with the first half of the implementation here:
>> https://github.com/apple/swift/pull/11501
>>
>> The piece that is missing is code generation support.
>>
>> -Chris
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
