Closed trevex closed 5 years ago
It is extremely unlikely that we will add any support for shared-variable concurrency to Starlark. Starlark was designed for use in an application in which millions of pure Starlark functions are executed in parallel, but none of those functions share variables with any other thread. All variables must be frozen before they are published to another thread. This model allows each thread to use and update local variables in the traditional imperative way, but avoids the whole problem of data races at a stroke. I wonder whether your problem can be reframed that way.
Could you give an example of the kind of program you'd like to be able to write?
Hmm, I am wondering whether I can reframe the problem. I'll have to think over that some more.
In the meantime: As state I am trying to automate operation tasks. This is currently only a hobby project however. I noticed particular patterns and pitfalls of devops processes and basically want to use starlark to script operational tasks and bundle them with the applications, so that oncallees or other teams can easily operate those applications. Basically an idea, that you can package those tasks inherit other tasks and end up with a full toolkit of all tasks related to the deployment you are working with (which is composed out of many components by different teams) Examples for those specific tasks could be: Downscaling etcd or cockroachdb, updating policies on a queuing system (like rabbitmq), migrating storage volumes etc, but could also be as simple as updating kubernetes deployments.
As I want to give the devops engineer in this scenario as much control as possible. I would love to enable them to run starlark code async as well. This mainly concerns REST APIs and executing commands however, which I could provide by other means as well, e.g. a request api might return a builtin type wrapping a go channel. Therefore the main gain would probably be ergonomic in my case.
I'm going to close this issue. Feel free to reopen it with a more specific request when you've had a chance to think it over.
I have been using starlark-go for a side-project trying to automate operational tasks. As some tasks are fairly long running and basically waiting for a server response, it would be handy to have access to a
async
/await
feature.I would be glad to help out, but while I have implemented interpreters before, my understanding of the starlark-go internals is currently superficial. From my current understanding major changes to function calls will be necessary to handle asynchronicity as frames have to be isolated and guarded against race conditions.
For now it would be interesting to hear your thoughts whether this feature aligns with starlark-go's goals, what specific changes would be necessary and how soundness can be guaranteed?