Bifrost Python Shell Support

[ccmcintyre-kingsds]

Importing Bifrost into a Python Shell / REPL which allows for line by line code execution by the user in real time immediately renders the environment unusable, slowing down even user input keystroke-by-keystroke into an excruciating and unreliable excercise. At its worst, this behaviour can even make the process difficult or impossible to exit, or even persist into the user's terminal session after exiting the Python Shell.

This has been observed on Ubuntu 18, Ubuntu 20, and Windows 7 through 10, in various versions of Python 3.

As Python is an interpreted language which is very frequently used as such in REPL environments, it is absolutely critical that we are able to support Python Shell usage of Bifrost.

I've tried lesioning the following pieces entirely out, and the behaviour still did not relent:

• NodeSTDProc, in py_nodejs.py
• inputStream, in main.js
• evaluator, in main.js

I suspect either something related to the Python-side ReadWriteLock, or something related to the shared memory mapping subprocesses broadly. It could still be the streaming pipes as well, but if so, probably more diagnosable on the Python side. Further investigation will absolutely be required. I doubt that this will be a quick or easy solve, but it will probably lead to significant performance and functionality gains across the board, even outside of REPL usage, if we can figure this out.

[ccmcintyre-kingsds]

It may be worth investigating whether some of the older versions of Bifrost were able to run gracefully in an interpreted Python Shell / REPL. If "yes", we can track down the point of regression. If "no", we can rule out potential sources accordingly.

[wesgarland]

There's a good chance you can get some clues by stracing the running REPL -- find out what is actually going on at the system call layer.

I suspect that the problem is not on the JS side, since I can't see how another process could affect the REPL itself. Unless the program is constantly making blocking calls to poll the pipeline to the other process or something? In which case, it would show in the call trace, and might be possible to uber-cheapen by communicating read readiness via posix async signals. Although....a select() call between keystrokes should not be expensive enough to notice unless you're typing 10E5 wpm.

[ccmcintyre-kingsds]

@wesgarland

There's a good chance you can get some clues by stracing the running REPL -- find out what is actually going on at the system call layer.

This is an extremely helpful suggestion, thank you!

I suspect that the problem is not on the JS side

I suspect that you're entirely correct, especially as blocking out major segments of the JS code has no effect on the behaviour whatsoever.

Unless the program is constantly making blocking calls to poll the pipeline to the other process or something

Certain critical parts of Bifrost's multi-part interop are doing almost exactly this, in my limited understanding, potentially even in ways that are inefficient enough to cause noticable problems. As you say, the tracing should give insight, which I'll follow up on, and at a guess you're probably also very right about the cheapening strategies. Further details pending.