Re: Multiple interpreter instances
- Posted by jimcbrown (admin) Mar 02, 2015
- 3225 views
I have had an idea several years ago. What if the euphoria "backend" was able to run in multiple instances, each instance in a different thread?
Looks like I beat you to it. http://scm.openeuphoria.org/hg/euphoria/shortlog/335f3b5cd19b
I need to study the internal working of OE more, but i believe it would require converting all global state data to be put inside arrays/sequences and add a manager that can create and destroy instances, each with it's own index/id number, and a sharing interface which all instances can access, with some sort of semaphore mechanism.
In my version, each thread has its own copy of everything, and only accesses that. So by default all variables are unique to a thread. (Not yet implemented.) For the future, there was to be a special shared data instance for variables that were declared to be shared between threads, that each thread would access in common. (Not yet implemented.)
This would open up some interesting possibilities:
- Multi-threading and blocking I/O would be possible, because a new thread would actually be a different interpreter, completely independent.
Yep. This already works in the experimental branch.
- Processing data with multiple cores would be possible, by starting multiple instances of the same code (library or routine) on multiple cores.
Yep. This already works.
- A eui.dll or eui.so could be linked to a main program to execute euphoria code, and share data with that program using the same system that shares data between interpreter instances.
This is more-or-less how the experimental branch is implemented.
- Running scripts or generating code on-the-fly would be possible, by simply starting a new interpreter instance.
Not in this implementation. All Euphoria code is compiled into IL first, and a single static, unmodifiable instance of IL is shared between all threads. (Since it's effectively read-only, this is thread-safe.)
- By adding a few built-in routines, a "interpreter instance" or "thread" manager could be accessed to start, stop, or monitor threads, as well as share data between them in a thread-safe way.
I hadn't gotten this far yet. Only starting threads is supported. Though one can still wrap the lower level OS/libc routines to manage native threads.
