3 ms·
You have at least convinced me that anyone using it would need to know very well what they are doing and what is going to happen behind the scenes. And that it'
by llimos 6y ago
You have at least convinced me that anyone using it would need to know very well what they are doing and what is going to happen behind the scenes. And that it's better suited to the higher-level languages (node, ruby family) rather than those that give you more fine-grained control over processes.
You've also convinced me that it's better as syntactic sugar for splitting into true separate processes behind the scenes, rather than a first-class language construct. This would solve many of the issues you raised. But I do still think there's value in such a concept.
Perhaps it could be a good fit for serverless functions. You write it as one function, but it happens as two, and the developer doesn't have to worry about the glue code.
In terms of jumping to the right place in the code, several languages have the concept of continuations, it doesn't seem like a huge leap to something like this.
- btrask 6y ago> Perhaps it could be a good fit for serverless functions. I was thinking of that too. :) If you're interested in the technical mechanism, it's possible to load a core dump and resume execution. I found https://web.archive.org/web/20091026234235/http://geocities.com/asimshankar/checkpointing/ https://web.archive.org/web/20091026234235/http://geocities.... which explains the (surprisingly complex) process of resuming from a core dump. Also see https://criu.org/ https://criu.org/ and https://checkpointing.org/ https://checkpointing.org/
- llimos 6y agoCool, very interesting! That just convinces me even more that it's better to leave the OS out of it and let each language's runtime figure out its own way of serializing its state and restoring it for a second invocation.