(Apologies for the broken threading on this reply, I'm just getting the list
access set up.)
Put each Python in a separate process and communicate by IPC.
I thought of that, but the multi-user program is a virtual machine
implementation, and the programs running on the machine have resources
Okay. Before you go one micron further, answer this critical question:
*Do you trust your users?*
The basic answer is yes. This program amounts to a virtual machine
implementation of a multi-processor and multi-user mainframe computer. It
runs on a Windows box of its own. It has an IO subsyst
We need to understand first what the process/threading/per-user model of
the existing application is.
The program is a virtual machine for an old mainframe architecture. You
could think of a VM running a Linux implementaiton as a kind of crude mental
reference model.
The emulated mainframe i
the multi-user program is a virtual machine
implementation
and the programs running on the machine have resources
like variables, arrays, files, and databases
Python variables? Python arrays (lists? tuples?)? Or some other sort of
"variables" and "arrays" that exist outside of Python?
You _re
"Loren Wilton" writes:
I don't think my main concern here is being able to call the CPython
interpreter routines, but instead it is to be able to provide separate
sandboxes for the various programs ("stacks", in B6500 terminology)
that might have their own Python sessio
[Cue the decades-old story about the elaborate set of C macros that I
once saw somebody using so he could write a C program that looked like
some flavor of structured BASIC.]
I once wrote a set pf C defines so that I could compile Pascal with a C
compiler without having to change the Pascal sou
So I take it that currently users access the software running in the
virtual mainframe over telnet or some form of serial link and that they
interact with it in a text terminal? This point is fairly important,
because if it's true, then you really don't have any in-band way of
clients talking to
Ah, that probably means you want separate interpreters, then.
I hope not, unless I can get separate simultaneous interpreters out of one
CPython.dll in one Windows process space. I'm guessing that I can't, but
since I really don't know what I'm doing with Python yet, maybe I'm wrong
there.
Oops, apologies for replying to the wrong thread!
Loren
--
https://mail.python.org/mailman/listinfo/python-list
No idea as it's still not clear what you want to accomplish exactly.
You are providing a lot of details, just not concrete ones that show how
things are currently done and how you want to change that by adding
Python to the mix.
Hum, this could take a lot of pages of text to describe how the exi
From: "Paul Rubin"
I don't think Python threads are the answer. You want a separate
interpreter per user, which is annoying to do with CPython. Do you have
concrete performance expectations about the sharing of data between
interpreter sessions? Those old mainframes were very slow compared to
To be fair, the sharing of data between threads is no different from
other concerns about global state. The only thing threads change is
that you can have multiple functions doing stuff at once.
state = [1,2,3]
def func():
state[1] += 5
# do work
state[1] -= 5
It occurs to me that thr
I still don't understand why this has to be in the same process space as
the VM. Wouldn't it be a lot simpler to create a simple RPC layer (all
localhost of course) to interface between the VM and a Python server
that spins up multiple processes or sessions? Kind of like how Python
for a web ser
Honestly, the best implementation strategy I can think of is to first
implement a Python interpreter for the actual mainframe environment.
Then invent an RPC layer that can semi-transparently bridge the two for
when you want to call a module that only exists in the Windows
environment (or call _fr
14 matches
Mail list logo
