Question on multiple Python users in one application

[Loren Wilton]

> 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 some Python process(es) running on the machine
> hosting the virtual mainframe.

Um... Yes and no.

Consider a Linux web server environment that happens to have Python 
installed.

A programmer in the organization that ownns the server can probably log on 
with an SSH session and type Python and then have an interactive Python 
session where does simple computations or database accesses, or where he 
runs existing Python scripts.

But that isn't how the machine will normally run.

Normally the web pages might have queries or other items that run bits of 
Python code, or Python scripts, some of which might access or even update a 
database. Normally there might be nightly cron jobs, some of which might be 
Pyton scripts.

> then you really don't have any in-band way of
> clients talking to some Python process(es) running on the machine
> hosting the virtual mainframe.

I'm not clear on what you mean by "in band way". If you mean that there is 
something on the Windows side of the machine that might wake up and decide 
it wants to talk to Python, then no, that can't happen.

But mainframes these days are generally not interactive in the sense of a 
Telent terminal. The programming machines have something like that, but the 
production machines usualy don't. There may be terminals, but they are 
probably automatic teller machines, or airline reservation terminals. These 
don't interact with a shell in the Unix sense, they interact with a series 
of predefined transaction commands that control program access, or maybe are 
accessed by a single dedicated program. Even web pages, if well written, can 
only access fixed assets.


>> 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 sessions or programs.
>
> You'll just have to implement Python support for these frames of
> reference. Python is not going to be running on the virtual hardware;
> it's running on Windows.  All you need to do is provide a way for the
> remote end users to talk to the Python server running on the windows
> machine would define sessions for the users and manage the interaction
> with the virtual mainframe.  No matter how you cut it, Python is
> separate from the users and separate from the mainframe since you can't
> run Python on the mainframe itself.  The only thing that makes sense is
> to develop some kind of Python-based server architecture that clients
> can talk to to do things via Python on behalf of the user.

If I need to write these sort of hooks, I'm new enough to Python to not have 
much of a clue where to start, and would appreciate all the help I can get.

I've read that Python supports 'threads', and I'd assumed (maybe 
incorrectly) that these were somewhat separate environments that could be 
operating concurrently (modulo the GC lock). I assume that data can be 
shared between the threads, and probably will share automatically if the 
name of the item (or the reference) matches. But I'd also assumed that I 
might be able to do something like start a thread and tell it that it is 
working in "module user_42" or some such, so that by default it's data would 
not be global.

Assuming that I'm not completely off-base about using threads, I don't 
really understand how to create a thread or destroy it. I'm also not 
completely clear on how much useful data there is that is thread local, and 
how much in the way of Python objects goes in the gloabl heap.

Would using threads help me do what I want? Or am I completely off base? Or 
is there some other approach that I've missed that might be better?

        Loren