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 is a multi-processor machine. We use separate threads
to represent each physical processor, and those threads are assigned to
separate real Intel processors underneath the program, in Windows. A given
user program can have multiple threads. Each thread can be running or
waiting for something.
If the user thread is running it will be on one of the virtual processors,
so will be on some one of the processor threads in the application. The user
thread can be interrupted by an IO completion interrupt or timer interrupt
or give up control in some way, and be kicked off the virtual processor.
When next run it might be on some other virtual processor, and thus on some
other thread in the VM application. Again, this is just like a normal user
program running in say Linux. So the VM application has many "processor"
threads, but a user does not correspond (except transiently) to any given
processor thread.
The VM also has a number of other threads for various purposes. It would be
possible to make a dedicated thread for each user that started a Python
program. This could get messy to manage, and there is always the possibility
of runnnig out of threads, but it might be a simple way to keep things
separated. I think that might allpw Python to use thread local storage to
some advantage, if I've understood the docs thatI've read correctly.
Loren
--
https://mail.python.org/mailman/listinfo/python-list
