Multiple interpreter instances
- Posted by ryanj Mar 01, 2015
- 3310 views
Forked from Re: string_exec()
Unless we're talking about this as something sandboxed away from the current program.
That's the easiest version to implement though. Just do it eueval-style (aka turning eu.ex into a library). (And even here, eueval5.0 could easily be modified to recreate and throw actual exceptions to the caller, if a fatal or uncaught exception was detected in the simulated code.)
From my point of view this is the only way to implement!
Eval in the current program is something i do not want to even think about.
(eval needs to live in a Sandbox and nowhere else!)
Thank you
Andreas
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? 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. 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.
- Running scripts or generating code on-the-fly would be possible, by simply starting a new interpreter instance.
- Processing data with multiple cores would be possible, by starting multiple instances of the same code (library or routine) on multiple cores.
- 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.
- 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.
What do you think?
