Mass checkin (more to follow for other directories).
Introduce truly separate (sub)interpreter objects. For now, these
must be used by separate threads, created from C. See Demo/pysvr for
an example of how to use this. This also rationalizes Python's
initialization and finalization behavior:
Py_Initialize() -- initialize the whole interpreter
Py_Finalize() -- finalize the whole interpreter
tstate = Py_NewInterpreter() -- create a new (sub)interpreter
Py_EndInterpreter(tstate) -- delete a new (sub)interpreter
There are also new interfaces relating to threads and the interpreter
lock, which can be used to create new threads, and sometimes have to
be used to manipulate the interpreter lock when creating or deleting
sub-interpreters. These are only defined when WITH_THREAD is defined:
PyEval_AcquireLock() -- acquire the interpreter lock
PyEval_ReleaseLock() -- release the interpreter lock
PyEval_AcquireThread(tstate) -- acquire the lock and make the thread current
PyEval_ReleaseThread(tstate) -- release the lock and make NULL current
Other administrative changes:
- The header file bltinmodule.h is deleted.
- The init functions for Import, Sys and Builtin are now internal and
declared in pythonrun.h.
- Py_Setup() and Py_Cleanup() are no longer declared.
- The interpreter state and thread state structures are now linked
together in a chain (the chain of interpreters is a static variable
in pythonrun.c).
- Some members of the interpreter and thread structures have new,
shorter, more consistent, names.
- Added declarations for _PyImport_{Find,Fixup}Extension() to import.h.
diff --git a/Include/pystate.h b/Include/pystate.h
index b660ff8..ad91426 100644
--- a/Include/pystate.h
+++ b/Include/pystate.h
@@ -42,15 +42,19 @@
#define NEXITFUNCS 32
+struct _ts; /* Forward */
+struct _is; /* Forward */
+
typedef struct _is {
- PyObject *import_modules;
+ struct _is *next;
+ struct _ts *tstate_head;
+
+ PyObject *modules;
PyObject *sysdict;
+ PyObject *builtins;
- int nthreads;
-
- void (*exitfuncs[NEXITFUNCS])();
- int nexitfuncs;
+ int checkinterval;
} PyInterpreterState;
@@ -61,7 +65,8 @@
typedef struct _ts {
- PyInterpreterState *interpreter_state;
+ struct _ts *next;
+ PyInterpreterState *interp;
struct _frame *frame;
int recursion_depth;
@@ -70,7 +75,6 @@
PyObject *sys_profilefunc;
PyObject *sys_tracefunc;
- int sys_checkinterval;
PyObject *curexc_type;
PyObject *curexc_value;
@@ -80,54 +84,22 @@
PyObject *exc_value;
PyObject *exc_traceback;
- /* XXX Other state that should be here:
- - signal handlers
- - low-level "pending calls"
- Problem with both is that they may be referenced from
- interrupt handlers where there is no clear concept of a
- "current thread"???
- */
+ /* XXX signal handlers should also be here */
} PyThreadState;
PyInterpreterState *PyInterpreterState_New Py_PROTO((void));
+void PyInterpreterState_Clear Py_PROTO((PyInterpreterState *));
void PyInterpreterState_Delete Py_PROTO((PyInterpreterState *));
PyThreadState *PyThreadState_New Py_PROTO((PyInterpreterState *));
+void PyThreadState_Clear Py_PROTO((PyThreadState *));
void PyThreadState_Delete Py_PROTO((PyThreadState *));
PyThreadState *PyThreadState_Get Py_PROTO((void));
PyThreadState *PyThreadState_Swap Py_PROTO((PyThreadState *));
-/* Some background.
-
- There are lots of issues here.
-
- First, we can build Python without threads, with threads, or (when
- Greg Stein's mods are out of beta, on some platforms) with free
- threading.
-
- Next, assuming some form of threading is used, there can be several
- kinds of threads. Python code can create threads with the thread
- module. C code can create threads with the interface defined in
- python's "thread.h". Or C code can create threads directly with
- the OS threads interface (e.g. Solaris threads, SGI threads or
- pthreads, whatever is being used, as long as it's the same that
- Python is configured for).
-
- Next, let's discuss sharing of interpreter state between threads.
- The exception state (sys.exc_* currently) should never be shared
- between threads, because it is stack frame specific. The contents
- of the sys module, in particular sys.modules and sys.path, are
- generally shared between threads. But occasionally it is useful to
- have separate module collections, e.g. when threads originate in C
- code and are used to execute unrelated Python scripts.
- (Traditionally, one would use separate processes for this, but
- there are lots of reasons why threads are attractive.)
-
-*/
-
#ifdef __cplusplus
}
#endif