Re: [phix] what is a hybrid interpreter compiler?
- Posted by jimcbrown (admin) Feb 01, 2021
- 1060 views
Not sure this is the right place or time to ask this...
Maybe i am just in a "ok, this can be hacked!" mood...
Can Phix say "hybrid" means a second stand-alone program can be "interpreted" and stashed in ram, and then a task (from tasks.e) be pointed at it? The "why" is so if the 2nd program crashes, it doesn't take the main program down with it.
Maybe i am using the wrong words again.
Kat
Makes perfect sense to me! In fact, I can see a trival OE implementation of this as follows:
First program creates the stash in ram.
First program creates a pipe and dumps stash from ram into it.
First program launches stub as a new process, passing it the pipe somehow (on nix, just passing the fd on the command line most likely, and the stub knows to grab it from there and how to open the pipe from then on).
Stub reads from the pipe and stashes it into ram again.
Stub does whatever magickery is required (e.g. mmap() to make allocated memory executable) and then makes a machine level call into the ram stash.
If the ram stash returns, stub exits.
If exchange of variables is desired while both proccesses are running, pass them through the pipe and have the processes signal each other when data is ready (on nix, using signal(8) to do so).
Tweak as desired (for example, replacing the pipe with some implementation of shared memory, changing process to native thread, using windoze API instead of nix stuff, etc).
Grand sweeping statements about this sort of thing would be so littered with ifs and buts and dos and donts if accurate they would be unreadable, but I'll give it a go.
Seems quite readable to me!
The hybrid connection : a Phix global program running on a cluster could be running compiled and interpreted processes on multiple machines, different OSs, as one program.
Reminds me of how Plan9 allows one to specify the cpu that a program runs on .. which may be on a different box over the network - and of a different type (so one could mix Intel with MIPS and have them appear to run on the same computer).
I agree with all you said, but you seem to have missed i was referring to completely separate processes, not tasks as OE does tasks now.
and being it's a separate task, calling it a task seems to fit.
No disagreements from me on that point. That said, in situations like this, I like to make up a new term (or sometimes multiple new terms) which helps other people avoid confusion. (I'm still using the old word in my head with my own meaning, and have to "translate" it when I write.) For example, https://openeuphoria.org/forum/m/126054.wc
YMMV
When declaring the type, i preceed the native OE types which i want to share with the word "global", and the preprocessor takes care of the machinery behind the scenes.
I'd probably have introduced a new keyword like 'shared' or 'universal' as 'global is already a keyword with a specific meaning in OE/Phix. NABD.
I use IPC now (but toying with TCP across the lan) to communicate back and forth between processes, and i can share selected functions, proceedures, and variables. The RDS trace/debug console functions with each separate process as normal. But it feels like this performance would be better served if it was part of the language,
Nice!
I think, in addition to support from the language/compiler+standard language libraries, the best performance would be gained if the OS also provided explicit support for this scenario. (Admittedly, this gets trickier as you try to use more and more OSes.) And how cool would it be if we could shared these things, not just between computers or between OSes, but between different languages? That said, one has to start somewhere, and your suggestion is a good one to start with.
