+1 - I agree with everything in the proposal.
-
I agree that
asynccalls from an actor-isolated function should not be guaranteed to run on the actor's executor. Aspects of the actor design (such as reentrancy) suggest to me that they are designed for maximum throughput while allowing safe access to isolated data, not for performing suspending operations on the actor's executor - i.e. it seems to me that the best way to use an actor is to quickly read any state you need up-front, perform any operations with that data on your own time, then return to the actor only to update its state. -
I agree that all arguments and return values of
asyncfunctions must beSendable. I actually had a draft reply to the Improving Sendable pitch which arrived at the same conclusion. Unfortunately I was distracted by other things and forgot to post it (I sometimes write draft replies, then leave them to stew for a bit while I think about things a bit more). Here was my reasoning, which is more about the underlying threads tasks are ultimately scheduled on and types with reference semantics than the more formal reasoning in this proposal:
One thing that I've been wondering about (and perhaps this is the right place to bring it up) is whether we should require that arguments to all
asyncfunctions areSendable.My understanding is that we want
Sendableenforcement to eventually become a guarantee against data races. If you pass some data in to anasyncfunction, we have no idea whether or not there are other references to its memory, whether it has been passed to any otherasyncfunctions, and whether any of them will mutate the memory's contents. And when the function you are calling suspends, we don't know which thread it's ultimately going to resume on, and whether or not its reads will be serialised with writes from other functions or overlap with them.The thing that gives us those guarantees is
Sendable.
So yeah, these look like good, important changes to me.