Open ales-tsurko opened 4 years ago
This is exciting. Have you thought about how concurrency would work for a Rust implementation? Would you make an Io VM with it's own stacks?
Have you thought about how concurrency would work for a Rust implementation?
I thought about using a library for this. There's a well known actix and other implementations of the actor model in the rust infra.
Would you make an Io VM with it's own stacks?
I'm really not sure about this for now. But I'll do research as there's no deadlines and I'm interested in this for educational purposes.
One thing I learned from my Go implementation: it's impossible to implement an Io scheduler that is itself concurrent and that provides worry-free consistency.
In order to achieve consistency with a goroutine per coroutine, without adding explicit synchronization mechanisms to Io, setSlot
has to hold a mutex for that slot during the entire time it evaluates the assignment value. This means that any use of any slot on an object accessible to another coroutine can potentially deadlock. (It was very neat to optimize slot accesses under this approach, though.)
I've been busy with school and other projects, but when I eventually return to iolang, I plan to turn its scheduler into the same one-at-a-time model that Io uses, and make an addon for goroutine concurrency/parallelism.
As an unrelated note, my implementation does currently run in Wasm. Although, last I tried, it deadlocked during tests on futures.
Thank you very much! I'll look into this issue first.
@stevedekorte @zephyrtronium Is there anything you'd do differently if you were rewriting it from scratch?
Is there anything you'd do differently if you were rewriting it from scratch?
The things that come to mind are:
Using a VM to isolate Io's concurrency and garbage collection from the implementation's. This ensures we can have things like coroutines, weak references, dynamic compilation, and mobile actors and images, regardless of implementation language.
An integrated persistence system. Probably a low level image model as well as a high level model (a library) where there is more control over how and when persistence occurs
An abstraction for slots
A notification system built around the slot abstraction that can help with synchronization between UI, objects, and storage
some form of capabilities based security system
a protocol for a uniform introspection and interaction with abstract objects that allowed UIs and associated storage to be automatically generated/managed from models
If you mean "what would I do to have a better time writing Io," I'd implement coroutines early – maybe before even messages – instead of leaving them for almost last, and I'd care about the performance of message passing itself before implementing all the methods of Number and Sequence. Even with heavy optimization, my implementation is still about 8-10x slower than the original, and it took multiple rewrites to get it there from 20x.
I also think I'd use singleton globals and not bother supporting multiple interpreter instances per program. This is probably more relevant for Go with its unusual calling convention, but eliminating an argument from every function should give a reasonable performance improvement, and it would make writing CFunctions slightly more convenient. There are few use cases for multiple interpreters, especially now that web REPLs can use Wasm instead of server-side processes.
Alternatively, if you mean "what would I do if inventing Io," static typing.
Thanks, guys! I need to return to Io and its sources after more than a year (or two?..) break. Then I'll research about everything you wrote. After that I'd write you personally if I had questions. Would you mind?
I'd be happy to talk more about your project.
I'm happy to answer questions as well. 🙂
I'm thinking of re-implementing Io in Rust. It's going to be a weekend side project, so the development is going to be slow. Some pros for motivation:
Are there any suggestions and wishes for this port?
@stevedekorte