blob: 4057f2fef137a9e57adea91211fae0c346b130be [file] [log] [blame]
Fred Drake3adf79e2001-10-12 19:01:43 +00001\chapter{Initialization, Finalization, and Threads
2 \label{initialization}}
3
4\begin{cfuncdesc}{void}{Py_Initialize}{}
5 Initialize the Python interpreter. In an application embedding
6 Python, this should be called before using any other Python/C API
7 functions; with the exception of
8 \cfunction{Py_SetProgramName()}\ttindex{Py_SetProgramName()},
9 \cfunction{PyEval_InitThreads()}\ttindex{PyEval_InitThreads()},
10 \cfunction{PyEval_ReleaseLock()}\ttindex{PyEval_ReleaseLock()},
11 and \cfunction{PyEval_AcquireLock()}\ttindex{PyEval_AcquireLock()}.
12 This initializes the table of loaded modules (\code{sys.modules}),
13 and\withsubitem{(in module sys)}{\ttindex{modules}\ttindex{path}}
14 creates the fundamental modules
15 \module{__builtin__}\refbimodindex{__builtin__},
16 \module{__main__}\refbimodindex{__main__} and
17 \module{sys}\refbimodindex{sys}. It also initializes the module
18 search\indexiii{module}{search}{path} path (\code{sys.path}).
19 It does not set \code{sys.argv}; use
20 \cfunction{PySys_SetArgv()}\ttindex{PySys_SetArgv()} for that. This
21 is a no-op when called for a second time (without calling
22 \cfunction{Py_Finalize()}\ttindex{Py_Finalize()} first). There is
23 no return value; it is a fatal error if the initialization fails.
24\end{cfuncdesc}
25
26\begin{cfuncdesc}{int}{Py_IsInitialized}{}
27 Return true (nonzero) when the Python interpreter has been
28 initialized, false (zero) if not. After \cfunction{Py_Finalize()}
29 is called, this returns false until \cfunction{Py_Initialize()} is
30 called again.
31\end{cfuncdesc}
32
33\begin{cfuncdesc}{void}{Py_Finalize}{}
34 Undo all initializations made by \cfunction{Py_Initialize()} and
35 subsequent use of Python/C API functions, and destroy all
36 sub-interpreters (see \cfunction{Py_NewInterpreter()} below) that
37 were created and not yet destroyed since the last call to
38 \cfunction{Py_Initialize()}. Ideally, this frees all memory
39 allocated by the Python interpreter. This is a no-op when called
40 for a second time (without calling \cfunction{Py_Initialize()} again
41 first). There is no return value; errors during finalization are
42 ignored.
43
44 This function is provided for a number of reasons. An embedding
45 application might want to restart Python without having to restart
46 the application itself. An application that has loaded the Python
47 interpreter from a dynamically loadable library (or DLL) might want
48 to free all memory allocated by Python before unloading the
49 DLL. During a hunt for memory leaks in an application a developer
50 might want to free all memory allocated by Python before exiting
51 from the application.
52
53 \strong{Bugs and caveats:} The destruction of modules and objects in
54 modules is done in random order; this may cause destructors
55 (\method{__del__()} methods) to fail when they depend on other
56 objects (even functions) or modules. Dynamically loaded extension
57 modules loaded by Python are not unloaded. Small amounts of memory
58 allocated by the Python interpreter may not be freed (if you find a
59 leak, please report it). Memory tied up in circular references
60 between objects is not freed. Some memory allocated by extension
Michael W. Hudsonbbe17f52003-02-10 19:12:42 +000061 modules may not be freed. Some extensions may not work properly if
Fred Drake3adf79e2001-10-12 19:01:43 +000062 their initialization routine is called more than once; this can
Michael W. Hudsonbbe17f52003-02-10 19:12:42 +000063 happen if an application calls \cfunction{Py_Initialize()} and
Fred Drake3adf79e2001-10-12 19:01:43 +000064 \cfunction{Py_Finalize()} more than once.
65\end{cfuncdesc}
66
67\begin{cfuncdesc}{PyThreadState*}{Py_NewInterpreter}{}
68 Create a new sub-interpreter. This is an (almost) totally separate
69 environment for the execution of Python code. In particular, the
70 new interpreter has separate, independent versions of all imported
71 modules, including the fundamental modules
72 \module{__builtin__}\refbimodindex{__builtin__},
73 \module{__main__}\refbimodindex{__main__} and
74 \module{sys}\refbimodindex{sys}. The table of loaded modules
75 (\code{sys.modules}) and the module search path (\code{sys.path})
76 are also separate. The new environment has no \code{sys.argv}
77 variable. It has new standard I/O stream file objects
78 \code{sys.stdin}, \code{sys.stdout} and \code{sys.stderr} (however
79 these refer to the same underlying \ctype{FILE} structures in the C
80 library).
81 \withsubitem{(in module sys)}{
82 \ttindex{stdout}\ttindex{stderr}\ttindex{stdin}}
83
84 The return value points to the first thread state created in the new
Brett Cannon65d63422004-03-18 01:38:11 +000085 sub-interpreter. This thread state is made in the current thread
Fred Drake3adf79e2001-10-12 19:01:43 +000086 state. Note that no actual thread is created; see the discussion of
87 thread states below. If creation of the new interpreter is
88 unsuccessful, \NULL{} is returned; no exception is set since the
89 exception state is stored in the current thread state and there may
90 not be a current thread state. (Like all other Python/C API
91 functions, the global interpreter lock must be held before calling
92 this function and is still held when it returns; however, unlike
93 most other Python/C API functions, there needn't be a current thread
94 state on entry.)
95
96 Extension modules are shared between (sub-)interpreters as follows:
97 the first time a particular extension is imported, it is initialized
98 normally, and a (shallow) copy of its module's dictionary is
99 squirreled away. When the same extension is imported by another
100 (sub-)interpreter, a new module is initialized and filled with the
101 contents of this copy; the extension's \code{init} function is not
102 called. Note that this is different from what happens when an
103 extension is imported after the interpreter has been completely
104 re-initialized by calling
105 \cfunction{Py_Finalize()}\ttindex{Py_Finalize()} and
106 \cfunction{Py_Initialize()}\ttindex{Py_Initialize()}; in that case,
107 the extension's \code{init\var{module}} function \emph{is} called
108 again.
109
110 \strong{Bugs and caveats:} Because sub-interpreters (and the main
111 interpreter) are part of the same process, the insulation between
112 them isn't perfect --- for example, using low-level file operations
113 like \withsubitem{(in module os)}{\ttindex{close()}}
114 \function{os.close()} they can (accidentally or maliciously) affect
115 each other's open files. Because of the way extensions are shared
116 between (sub-)interpreters, some extensions may not work properly;
117 this is especially likely when the extension makes use of (static)
118 global variables, or when the extension manipulates its module's
119 dictionary after its initialization. It is possible to insert
120 objects created in one sub-interpreter into a namespace of another
121 sub-interpreter; this should be done with great care to avoid
122 sharing user-defined functions, methods, instances or classes
123 between sub-interpreters, since import operations executed by such
124 objects may affect the wrong (sub-)interpreter's dictionary of
125 loaded modules. (XXX This is a hard-to-fix bug that will be
126 addressed in a future release.)
127\end{cfuncdesc}
128
129\begin{cfuncdesc}{void}{Py_EndInterpreter}{PyThreadState *tstate}
130 Destroy the (sub-)interpreter represented by the given thread state.
131 The given thread state must be the current thread state. See the
132 discussion of thread states below. When the call returns, the
133 current thread state is \NULL. All thread states associated with
Brett Cannon9b976e62004-03-18 00:49:01 +0000134 this interpreter are destroyed. (The global interpreter lock must
Fred Drake3adf79e2001-10-12 19:01:43 +0000135 be held before calling this function and is still held when it
136 returns.) \cfunction{Py_Finalize()}\ttindex{Py_Finalize()} will
137 destroy all sub-interpreters that haven't been explicitly destroyed
138 at that point.
139\end{cfuncdesc}
140
141\begin{cfuncdesc}{void}{Py_SetProgramName}{char *name}
142 This function should be called before
143 \cfunction{Py_Initialize()}\ttindex{Py_Initialize()} is called
144 for the first time, if it is called at all. It tells the
145 interpreter the value of the \code{argv[0]} argument to the
146 \cfunction{main()}\ttindex{main()} function of the program. This is
147 used by \cfunction{Py_GetPath()}\ttindex{Py_GetPath()} and some
148 other functions below to find the Python run-time libraries relative
149 to the interpreter executable. The default value is
150 \code{'python'}. The argument should point to a zero-terminated
151 character string in static storage whose contents will not change
152 for the duration of the program's execution. No code in the Python
153 interpreter will change the contents of this storage.
154\end{cfuncdesc}
155
156\begin{cfuncdesc}{char*}{Py_GetProgramName}{}
157 Return the program name set with
158 \cfunction{Py_SetProgramName()}\ttindex{Py_SetProgramName()}, or the
159 default. The returned string points into static storage; the caller
160 should not modify its value.
161\end{cfuncdesc}
162
163\begin{cfuncdesc}{char*}{Py_GetPrefix}{}
164 Return the \emph{prefix} for installed platform-independent files.
165 This is derived through a number of complicated rules from the
166 program name set with \cfunction{Py_SetProgramName()} and some
167 environment variables; for example, if the program name is
168 \code{'/usr/local/bin/python'}, the prefix is \code{'/usr/local'}.
169 The returned string points into static storage; the caller should
170 not modify its value. This corresponds to the \makevar{prefix}
171 variable in the top-level \file{Makefile} and the
172 \longprogramopt{prefix} argument to the \program{configure} script
173 at build time. The value is available to Python code as
174 \code{sys.prefix}. It is only useful on \UNIX. See also the next
175 function.
176\end{cfuncdesc}
177
178\begin{cfuncdesc}{char*}{Py_GetExecPrefix}{}
179 Return the \emph{exec-prefix} for installed
180 platform-\emph{de}pendent files. This is derived through a number
181 of complicated rules from the program name set with
182 \cfunction{Py_SetProgramName()} and some environment variables; for
183 example, if the program name is \code{'/usr/local/bin/python'}, the
184 exec-prefix is \code{'/usr/local'}. The returned string points into
185 static storage; the caller should not modify its value. This
186 corresponds to the \makevar{exec_prefix} variable in the top-level
187 \file{Makefile} and the \longprogramopt{exec-prefix} argument to the
188 \program{configure} script at build time. The value is available
189 to Python code as \code{sys.exec_prefix}. It is only useful on
190 \UNIX.
191
192 Background: The exec-prefix differs from the prefix when platform
193 dependent files (such as executables and shared libraries) are
194 installed in a different directory tree. In a typical installation,
195 platform dependent files may be installed in the
196 \file{/usr/local/plat} subtree while platform independent may be
197 installed in \file{/usr/local}.
198
199 Generally speaking, a platform is a combination of hardware and
200 software families, e.g. Sparc machines running the Solaris 2.x
201 operating system are considered the same platform, but Intel
202 machines running Solaris 2.x are another platform, and Intel
203 machines running Linux are yet another platform. Different major
204 revisions of the same operating system generally also form different
205 platforms. Non-\UNIX{} operating systems are a different story; the
206 installation strategies on those systems are so different that the
207 prefix and exec-prefix are meaningless, and set to the empty string.
208 Note that compiled Python bytecode files are platform independent
209 (but not independent from the Python version by which they were
210 compiled!).
211
212 System administrators will know how to configure the \program{mount}
213 or \program{automount} programs to share \file{/usr/local} between
214 platforms while having \file{/usr/local/plat} be a different
215 filesystem for each platform.
216\end{cfuncdesc}
217
218\begin{cfuncdesc}{char*}{Py_GetProgramFullPath}{}
219 Return the full program name of the Python executable; this is
220 computed as a side-effect of deriving the default module search path
221 from the program name (set by
222 \cfunction{Py_SetProgramName()}\ttindex{Py_SetProgramName()} above).
223 The returned string points into static storage; the caller should
224 not modify its value. The value is available to Python code as
225 \code{sys.executable}.
226 \withsubitem{(in module sys)}{\ttindex{executable}}
227\end{cfuncdesc}
228
229\begin{cfuncdesc}{char*}{Py_GetPath}{}
230 \indexiii{module}{search}{path}
231 Return the default module search path; this is computed from the
232 program name (set by \cfunction{Py_SetProgramName()} above) and some
233 environment variables. The returned string consists of a series of
234 directory names separated by a platform dependent delimiter
235 character. The delimiter character is \character{:} on \UNIX,
Martin v. Löwis36a4d8c2002-10-10 18:24:54 +0000236 \character{;} on Windows, and \character{\e n} (the \ASCII{}
Fred Drake3adf79e2001-10-12 19:01:43 +0000237 newline character) on Macintosh. The returned string points into
238 static storage; the caller should not modify its value. The value
239 is available to Python code as the list
240 \code{sys.path}\withsubitem{(in module sys)}{\ttindex{path}}, which
241 may be modified to change the future search path for loaded
242 modules.
243
244 % XXX should give the exact rules
245\end{cfuncdesc}
246
247\begin{cfuncdesc}{const char*}{Py_GetVersion}{}
248 Return the version of this Python interpreter. This is a string
249 that looks something like
250
251\begin{verbatim}
252"1.5 (#67, Dec 31 1997, 22:34:28) [GCC 2.7.2.2]"
253\end{verbatim}
254
255 The first word (up to the first space character) is the current
256 Python version; the first three characters are the major and minor
257 version separated by a period. The returned string points into
258 static storage; the caller should not modify its value. The value
Michael W. Hudsonbbe17f52003-02-10 19:12:42 +0000259 is available to Python code as \code{sys.version}.
Fred Drake3adf79e2001-10-12 19:01:43 +0000260 \withsubitem{(in module sys)}{\ttindex{version}}
261\end{cfuncdesc}
262
263\begin{cfuncdesc}{const char*}{Py_GetPlatform}{}
264 Return the platform identifier for the current platform. On \UNIX,
265 this is formed from the ``official'' name of the operating system,
266 converted to lower case, followed by the major revision number;
267 e.g., for Solaris 2.x, which is also known as SunOS 5.x, the value
268 is \code{'sunos5'}. On Macintosh, it is \code{'mac'}. On Windows,
269 it is \code{'win'}. The returned string points into static storage;
270 the caller should not modify its value. The value is available to
271 Python code as \code{sys.platform}.
272 \withsubitem{(in module sys)}{\ttindex{platform}}
273\end{cfuncdesc}
274
275\begin{cfuncdesc}{const char*}{Py_GetCopyright}{}
276 Return the official copyright string for the current Python version,
277 for example
278
279 \code{'Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam'}
280
281 The returned string points into static storage; the caller should
Michael W. Hudsonbbe17f52003-02-10 19:12:42 +0000282 not modify its value. The value is available to Python code as
283 \code{sys.copyright}.
Fred Drake3adf79e2001-10-12 19:01:43 +0000284 \withsubitem{(in module sys)}{\ttindex{copyright}}
285\end{cfuncdesc}
286
287\begin{cfuncdesc}{const char*}{Py_GetCompiler}{}
288 Return an indication of the compiler used to build the current
289 Python version, in square brackets, for example:
290
291\begin{verbatim}
292"[GCC 2.7.2.2]"
293\end{verbatim}
294
295 The returned string points into static storage; the caller should
296 not modify its value. The value is available to Python code as part
297 of the variable \code{sys.version}.
298 \withsubitem{(in module sys)}{\ttindex{version}}
299\end{cfuncdesc}
300
301\begin{cfuncdesc}{const char*}{Py_GetBuildInfo}{}
302 Return information about the sequence number and build date and time
303 of the current Python interpreter instance, for example
304
305\begin{verbatim}
306"#67, Aug 1 1997, 22:34:28"
307\end{verbatim}
308
309 The returned string points into static storage; the caller should
310 not modify its value. The value is available to Python code as part
311 of the variable \code{sys.version}.
312 \withsubitem{(in module sys)}{\ttindex{version}}
313\end{cfuncdesc}
314
315\begin{cfuncdesc}{int}{PySys_SetArgv}{int argc, char **argv}
316 Set \code{sys.argv} based on \var{argc} and \var{argv}. These
317 parameters are similar to those passed to the program's
318 \cfunction{main()}\ttindex{main()} function with the difference that
319 the first entry should refer to the script file to be executed
320 rather than the executable hosting the Python interpreter. If there
321 isn't a script that will be run, the first entry in \var{argv} can
322 be an empty string. If this function fails to initialize
323 \code{sys.argv}, a fatal condition is signalled using
324 \cfunction{Py_FatalError()}\ttindex{Py_FatalError()}.
325 \withsubitem{(in module sys)}{\ttindex{argv}}
326 % XXX impl. doesn't seem consistent in allowing 0/NULL for the params;
327 % check w/ Guido.
328\end{cfuncdesc}
329
330% XXX Other PySys thingies (doesn't really belong in this chapter)
331
332\section{Thread State and the Global Interpreter Lock
333 \label{threads}}
334
335\index{global interpreter lock}
336\index{interpreter lock}
337\index{lock, interpreter}
338
339The Python interpreter is not fully thread safe. In order to support
340multi-threaded Python programs, there's a global lock that must be
341held by the current thread before it can safely access Python objects.
342Without the lock, even the simplest operations could cause problems in
343a multi-threaded program: for example, when two threads simultaneously
344increment the reference count of the same object, the reference count
345could end up being incremented only once instead of twice.
346
347Therefore, the rule exists that only the thread that has acquired the
348global interpreter lock may operate on Python objects or call Python/C
349API functions. In order to support multi-threaded Python programs,
350the interpreter regularly releases and reacquires the lock --- by
Skip Montanaroeec26f92003-07-02 21:38:34 +0000351default, every 100 bytecode instructions (this can be changed with
Fred Drake3adf79e2001-10-12 19:01:43 +0000352\withsubitem{(in module sys)}{\ttindex{setcheckinterval()}}
353\function{sys.setcheckinterval()}). The lock is also released and
354reacquired around potentially blocking I/O operations like reading or
355writing a file, so that other threads can run while the thread that
356requests the I/O is waiting for the I/O operation to complete.
357
358The Python interpreter needs to keep some bookkeeping information
359separate per thread --- for this it uses a data structure called
Andrew M. Kuchlingd9dfe022004-07-10 13:48:54 +0000360\ctype{PyThreadState}\ttindex{PyThreadState}. There's one global
361variable, however: the pointer to the current
Fred Drake3adf79e2001-10-12 19:01:43 +0000362\ctype{PyThreadState}\ttindex{PyThreadState} structure. While most
363thread packages have a way to store ``per-thread global data,''
364Python's internal platform independent thread abstraction doesn't
365support this yet. Therefore, the current thread state must be
366manipulated explicitly.
367
368This is easy enough in most cases. Most code manipulating the global
369interpreter lock has the following simple structure:
370
371\begin{verbatim}
372Save the thread state in a local variable.
373Release the interpreter lock.
374...Do some blocking I/O operation...
375Reacquire the interpreter lock.
376Restore the thread state from the local variable.
377\end{verbatim}
378
379This is so common that a pair of macros exists to simplify it:
380
381\begin{verbatim}
382Py_BEGIN_ALLOW_THREADS
383...Do some blocking I/O operation...
384Py_END_ALLOW_THREADS
385\end{verbatim}
386
Fred Drake375e3022002-04-09 21:09:42 +0000387The
388\csimplemacro{Py_BEGIN_ALLOW_THREADS}\ttindex{Py_BEGIN_ALLOW_THREADS}
389macro opens a new block and declares a hidden local variable; the
390\csimplemacro{Py_END_ALLOW_THREADS}\ttindex{Py_END_ALLOW_THREADS}
391macro closes the block. Another advantage of using these two macros
392is that when Python is compiled without thread support, they are
393defined empty, thus saving the thread state and lock manipulations.
Fred Drake3adf79e2001-10-12 19:01:43 +0000394
395When thread support is enabled, the block above expands to the
396following code:
397
398\begin{verbatim}
399 PyThreadState *_save;
400
401 _save = PyEval_SaveThread();
402 ...Do some blocking I/O operation...
403 PyEval_RestoreThread(_save);
404\end{verbatim}
405
406Using even lower level primitives, we can get roughly the same effect
407as follows:
408
409\begin{verbatim}
410 PyThreadState *_save;
411
412 _save = PyThreadState_Swap(NULL);
413 PyEval_ReleaseLock();
414 ...Do some blocking I/O operation...
415 PyEval_AcquireLock();
416 PyThreadState_Swap(_save);
417\end{verbatim}
418
419There are some subtle differences; in particular,
420\cfunction{PyEval_RestoreThread()}\ttindex{PyEval_RestoreThread()} saves
421and restores the value of the global variable
422\cdata{errno}\ttindex{errno}, since the lock manipulation does not
423guarantee that \cdata{errno} is left alone. Also, when thread support
424is disabled,
425\cfunction{PyEval_SaveThread()}\ttindex{PyEval_SaveThread()} and
426\cfunction{PyEval_RestoreThread()} don't manipulate the lock; in this
427case, \cfunction{PyEval_ReleaseLock()}\ttindex{PyEval_ReleaseLock()} and
428\cfunction{PyEval_AcquireLock()}\ttindex{PyEval_AcquireLock()} are not
429available. This is done so that dynamically loaded extensions
430compiled with thread support enabled can be loaded by an interpreter
431that was compiled with disabled thread support.
432
433The global interpreter lock is used to protect the pointer to the
434current thread state. When releasing the lock and saving the thread
435state, the current thread state pointer must be retrieved before the
436lock is released (since another thread could immediately acquire the
437lock and store its own thread state in the global variable).
438Conversely, when acquiring the lock and restoring the thread state,
439the lock must be acquired before storing the thread state pointer.
440
441Why am I going on with so much detail about this? Because when
442threads are created from C, they don't have the global interpreter
443lock, nor is there a thread state data structure for them. Such
444threads must bootstrap themselves into existence, by first creating a
445thread state data structure, then acquiring the lock, and finally
446storing their thread state pointer, before they can start using the
447Python/C API. When they are done, they should reset the thread state
448pointer, release the lock, and finally free their thread state data
449structure.
450
451When creating a thread data structure, you need to provide an
452interpreter state data structure. The interpreter state data
Brett Cannon65d63422004-03-18 01:38:11 +0000453structure holds global data that is shared by all threads in an
Fred Drake3adf79e2001-10-12 19:01:43 +0000454interpreter, for example the module administration
455(\code{sys.modules}). Depending on your needs, you can either create
456a new interpreter state data structure, or share the interpreter state
457data structure used by the Python main thread (to access the latter,
458you must obtain the thread state and access its \member{interp} member;
459this must be done by a thread that is created by Python or by the main
460thread after Python is initialized).
461
Guido van Rossum41bcbe32003-03-02 13:17:20 +0000462Assuming you have access to an interpreter object, the typical idiom
463for calling into Python from a C thread is
464
465\begin{verbatim}
Andrew M. Kuchlingff8113f2004-07-10 13:42:52 +0000466 PyGILState_STATE gstate;
467 gstate = PyGILState_Ensure();
Guido van Rossum41bcbe32003-03-02 13:17:20 +0000468
469 /* Perform Python actions here. */
470 result = CallSomeFunction();
471 /* evaluate result */
472
473 /* Release the thread. No Python API allowed beyond this point. */
Andrew M. Kuchlingff8113f2004-07-10 13:42:52 +0000474 PyGILState_Release(gstate);
Guido van Rossum41bcbe32003-03-02 13:17:20 +0000475\end{verbatim}
Fred Drake3adf79e2001-10-12 19:01:43 +0000476
477\begin{ctypedesc}{PyInterpreterState}
478 This data structure represents the state shared by a number of
479 cooperating threads. Threads belonging to the same interpreter
480 share their module administration and a few other internal items.
481 There are no public members in this structure.
482
483 Threads belonging to different interpreters initially share nothing,
484 except process state like available memory, open file descriptors
485 and such. The global interpreter lock is also shared by all
486 threads, regardless of to which interpreter they belong.
487\end{ctypedesc}
488
489\begin{ctypedesc}{PyThreadState}
490 This data structure represents the state of a single thread. The
491 only public data member is \ctype{PyInterpreterState
492 *}\member{interp}, which points to this thread's interpreter state.
493\end{ctypedesc}
494
495\begin{cfuncdesc}{void}{PyEval_InitThreads}{}
496 Initialize and acquire the global interpreter lock. It should be
497 called in the main thread before creating a second thread or
498 engaging in any other thread operations such as
499 \cfunction{PyEval_ReleaseLock()}\ttindex{PyEval_ReleaseLock()} or
500 \code{PyEval_ReleaseThread(\var{tstate})}\ttindex{PyEval_ReleaseThread()}.
501 It is not needed before calling
502 \cfunction{PyEval_SaveThread()}\ttindex{PyEval_SaveThread()} or
503 \cfunction{PyEval_RestoreThread()}\ttindex{PyEval_RestoreThread()}.
504
505 This is a no-op when called for a second time. It is safe to call
506 this function before calling
507 \cfunction{Py_Initialize()}\ttindex{Py_Initialize()}.
508
509 When only the main thread exists, no lock operations are needed.
510 This is a common situation (most Python programs do not use
511 threads), and the lock operations slow the interpreter down a bit.
512 Therefore, the lock is not created initially. This situation is
513 equivalent to having acquired the lock: when there is only a single
514 thread, all object accesses are safe. Therefore, when this function
515 initializes the lock, it also acquires it. Before the Python
516 \module{thread}\refbimodindex{thread} module creates a new thread,
517 knowing that either it has the lock or the lock hasn't been created
518 yet, it calls \cfunction{PyEval_InitThreads()}. When this call
519 returns, it is guaranteed that the lock has been created and that it
520 has acquired it.
521
522 It is \strong{not} safe to call this function when it is unknown
523 which thread (if any) currently has the global interpreter lock.
524
525 This function is not available when thread support is disabled at
526 compile time.
527\end{cfuncdesc}
528
529\begin{cfuncdesc}{void}{PyEval_AcquireLock}{}
530 Acquire the global interpreter lock. The lock must have been
531 created earlier. If this thread already has the lock, a deadlock
532 ensues. This function is not available when thread support is
533 disabled at compile time.
534\end{cfuncdesc}
535
536\begin{cfuncdesc}{void}{PyEval_ReleaseLock}{}
537 Release the global interpreter lock. The lock must have been
538 created earlier. This function is not available when thread support
539 is disabled at compile time.
540\end{cfuncdesc}
541
542\begin{cfuncdesc}{void}{PyEval_AcquireThread}{PyThreadState *tstate}
Brett Cannon65d63422004-03-18 01:38:11 +0000543 Acquire the global interpreter lock and set the current thread
Fred Drake3adf79e2001-10-12 19:01:43 +0000544 state to \var{tstate}, which should not be \NULL. The lock must
545 have been created earlier. If this thread already has the lock,
546 deadlock ensues. This function is not available when thread support
547 is disabled at compile time.
548\end{cfuncdesc}
549
550\begin{cfuncdesc}{void}{PyEval_ReleaseThread}{PyThreadState *tstate}
551 Reset the current thread state to \NULL{} and release the global
552 interpreter lock. The lock must have been created earlier and must
553 be held by the current thread. The \var{tstate} argument, which
554 must not be \NULL, is only used to check that it represents the
555 current thread state --- if it isn't, a fatal error is reported.
556 This function is not available when thread support is disabled at
557 compile time.
558\end{cfuncdesc}
559
560\begin{cfuncdesc}{PyThreadState*}{PyEval_SaveThread}{}
561 Release the interpreter lock (if it has been created and thread
562 support is enabled) and reset the thread state to \NULL, returning
563 the previous thread state (which is not \NULL). If the lock has
564 been created, the current thread must have acquired it. (This
565 function is available even when thread support is disabled at
566 compile time.)
567\end{cfuncdesc}
568
569\begin{cfuncdesc}{void}{PyEval_RestoreThread}{PyThreadState *tstate}
570 Acquire the interpreter lock (if it has been created and thread
571 support is enabled) and set the thread state to \var{tstate}, which
572 must not be \NULL. If the lock has been created, the current thread
573 must not have acquired it, otherwise deadlock ensues. (This
574 function is available even when thread support is disabled at
575 compile time.)
576\end{cfuncdesc}
577
578The following macros are normally used without a trailing semicolon;
579look for example usage in the Python source distribution.
580
581\begin{csimplemacrodesc}{Py_BEGIN_ALLOW_THREADS}
582 This macro expands to
583 \samp{\{ PyThreadState *_save; _save = PyEval_SaveThread();}.
584 Note that it contains an opening brace; it must be matched with a
Fred Drake375e3022002-04-09 21:09:42 +0000585 following \csimplemacro{Py_END_ALLOW_THREADS} macro. See above for
586 further discussion of this macro. It is a no-op when thread support
587 is disabled at compile time.
Fred Drake3adf79e2001-10-12 19:01:43 +0000588\end{csimplemacrodesc}
589
590\begin{csimplemacrodesc}{Py_END_ALLOW_THREADS}
591 This macro expands to \samp{PyEval_RestoreThread(_save); \}}.
592 Note that it contains a closing brace; it must be matched with an
Fred Drake375e3022002-04-09 21:09:42 +0000593 earlier \csimplemacro{Py_BEGIN_ALLOW_THREADS} macro. See above for
594 further discussion of this macro. It is a no-op when thread support
595 is disabled at compile time.
Fred Drake3adf79e2001-10-12 19:01:43 +0000596\end{csimplemacrodesc}
597
598\begin{csimplemacrodesc}{Py_BLOCK_THREADS}
599 This macro expands to \samp{PyEval_RestoreThread(_save);}: it is
Fred Drake375e3022002-04-09 21:09:42 +0000600 equivalent to \csimplemacro{Py_END_ALLOW_THREADS} without the
601 closing brace. It is a no-op when thread support is disabled at
602 compile time.
Fred Drake3adf79e2001-10-12 19:01:43 +0000603\end{csimplemacrodesc}
604
605\begin{csimplemacrodesc}{Py_UNBLOCK_THREADS}
606 This macro expands to \samp{_save = PyEval_SaveThread();}: it is
Fred Drake375e3022002-04-09 21:09:42 +0000607 equivalent to \csimplemacro{Py_BEGIN_ALLOW_THREADS} without the
608 opening brace and variable declaration. It is a no-op when thread
609 support is disabled at compile time.
Fred Drake3adf79e2001-10-12 19:01:43 +0000610\end{csimplemacrodesc}
611
612All of the following functions are only available when thread support
613is enabled at compile time, and must be called only when the
614interpreter lock has been created.
615
616\begin{cfuncdesc}{PyInterpreterState*}{PyInterpreterState_New}{}
617 Create a new interpreter state object. The interpreter lock need
618 not be held, but may be held if it is necessary to serialize calls
619 to this function.
620\end{cfuncdesc}
621
622\begin{cfuncdesc}{void}{PyInterpreterState_Clear}{PyInterpreterState *interp}
623 Reset all information in an interpreter state object. The
624 interpreter lock must be held.
625\end{cfuncdesc}
626
627\begin{cfuncdesc}{void}{PyInterpreterState_Delete}{PyInterpreterState *interp}
628 Destroy an interpreter state object. The interpreter lock need not
629 be held. The interpreter state must have been reset with a previous
630 call to \cfunction{PyInterpreterState_Clear()}.
631\end{cfuncdesc}
632
633\begin{cfuncdesc}{PyThreadState*}{PyThreadState_New}{PyInterpreterState *interp}
634 Create a new thread state object belonging to the given interpreter
635 object. The interpreter lock need not be held, but may be held if
636 it is necessary to serialize calls to this function.
637\end{cfuncdesc}
638
639\begin{cfuncdesc}{void}{PyThreadState_Clear}{PyThreadState *tstate}
640 Reset all information in a thread state object. The interpreter lock
641 must be held.
642\end{cfuncdesc}
643
644\begin{cfuncdesc}{void}{PyThreadState_Delete}{PyThreadState *tstate}
645 Destroy a thread state object. The interpreter lock need not be
646 held. The thread state must have been reset with a previous call to
647 \cfunction{PyThreadState_Clear()}.
648\end{cfuncdesc}
649
650\begin{cfuncdesc}{PyThreadState*}{PyThreadState_Get}{}
651 Return the current thread state. The interpreter lock must be
652 held. When the current thread state is \NULL, this issues a fatal
653 error (so that the caller needn't check for \NULL).
654\end{cfuncdesc}
655
656\begin{cfuncdesc}{PyThreadState*}{PyThreadState_Swap}{PyThreadState *tstate}
657 Swap the current thread state with the thread state given by the
658 argument \var{tstate}, which may be \NULL. The interpreter lock
659 must be held.
660\end{cfuncdesc}
661
662\begin{cfuncdesc}{PyObject*}{PyThreadState_GetDict}{}
663 Return a dictionary in which extensions can store thread-specific
664 state information. Each extension should use a unique key to use to
Guido van Rossum0fc8f002003-04-15 15:12:39 +0000665 store state in the dictionary. It is okay to call this function
666 when no current thread state is available.
667 If this function returns \NULL, no exception has been raised and the
668 caller should assume no current thread state is available.
669 \versionchanged[Previously this could only be called when a current
Fred Drake4ccf6e72003-09-07 02:32:55 +0000670 thread is active, and \NULL{} meant that an exception was raised]{2.3}
Fred Drake3adf79e2001-10-12 19:01:43 +0000671\end{cfuncdesc}
672
Fred Drake6595e152003-06-29 02:14:31 +0000673\begin{cfuncdesc}{int}{PyThreadState_SetAsyncExc}{long id, PyObject *exc}
674 Asynchronously raise an exception in a thread.
675 The \var{id} argument is the thread id of the target thread;
676 \var{exc} is the exception object to be raised.
677 This function does not steal any references to \var{exc}.
678 To prevent naive misuse, you must write your own C extension
679 to call this. Must be called with the GIL held.
680 Returns the number of thread states modified; if it returns a number
681 greater than one, you're in trouble, and you should call it again
682 with \var{exc} set to \constant{NULL} to revert the effect.
683 This raises no exceptions.
684 \versionadded{2.3}
685\end{cfuncdesc}
686
Andrew M. Kuchling371d98a2004-07-10 13:31:18 +0000687\begin{cfuncdesc}{PyGILState_STATE}{PyGILState_Ensure}{}
688Ensure that the current thread is ready to call the Python
689C API regardless of the current state of Python, or of its
690thread lock. This may be called as many times as desired
691by a thread as long as each call is matched with a call to
692\cfunction{PyGILState_Release()}.
693In general, other thread-related APIs may
694be used between \cfunction{PyGILState_Ensure()} and \cfunction{PyGILState_Release()} calls as long as the
695thread state is restored to its previous state before the Release().
696For example, normal usage of the \csimplemacro{Py_BEGIN_ALLOW_THREADS}
697and \csimplemacro{Py_END_ALLOW_THREADS} macros is acceptable.
698
699The return value is an opaque "handle" to the thread state when
700\cfunction{PyGILState_Acquire()} was called, and must be passed to
701\cfunction{PyGILState_Release()} to ensure Python is left in the same
702state. Even though recursive calls are allowed, these handles
703\emph{cannot} be shared - each unique call to
704\cfunction{PyGILState_Ensure} must save the handle for its call to
705\cfunction{PyGILState_Release}.
706
707When the function returns, the current thread will hold the GIL.
708Failure is a fatal error.
709 \versionadded{2.3}
710\end{cfuncdesc}
711
712\begin{cfuncdesc}{void}{PyGILState_Release}{PyGILState_STATE}
713Release any resources previously acquired. After this call, Python's
714state will be the same as it was prior to the corresponding
Andrew M. Kuchlingff8113f2004-07-10 13:42:52 +0000715\cfunction{PyGILState_Ensure} call (but generally this state will be
716unknown to the caller, hence the use of the GILState API.)
Andrew M. Kuchling371d98a2004-07-10 13:31:18 +0000717
718Every call to \cfunction{PyGILState_Ensure()} must be matched by a call to
719\cfunction{PyGILState_Release()} on the same thread.
720 \versionadded{2.3}
721\end{cfuncdesc}
722
Fred Drake3adf79e2001-10-12 19:01:43 +0000723
724\section{Profiling and Tracing \label{profiling}}
725
726\sectionauthor{Fred L. Drake, Jr.}{fdrake@acm.org}
727
728The Python interpreter provides some low-level support for attaching
729profiling and execution tracing facilities. These are used for
730profiling, debugging, and coverage analysis tools.
731
732Starting with Python 2.2, the implementation of this facility was
733substantially revised, and an interface from C was added. This C
734interface allows the profiling or tracing code to avoid the overhead
735of calling through Python-level callable objects, making a direct C
736function call instead. The essential attributes of the facility have
737not changed; the interface allows trace functions to be installed
738per-thread, and the basic events reported to the trace function are
739the same as had been reported to the Python-level trace functions in
740previous versions.
741
742\begin{ctypedesc}[Py_tracefunc]{int (*Py_tracefunc)(PyObject *obj,
743 PyFrameObject *frame, int what,
744 PyObject *arg)}
745 The type of the trace function registered using
746 \cfunction{PyEval_SetProfile()} and \cfunction{PyEval_SetTrace()}.
747 The first parameter is the object passed to the registration
748 function as \var{obj}, \var{frame} is the frame object to which the
749 event pertains, \var{what} is one of the constants
Nicholas Bastinc69ebe82004-03-24 21:57:10 +0000750 \constant{PyTrace_CALL}, \constant{PyTrace_EXCEPTION},
751 \constant{PyTrace_LINE}, \constant{PyTrace_RETURN},
752 \constant{PyTrace_C_CALL}, \constant{PyTrace_C_EXCEPTION},
753 or \constant{PyTrace_C_RETURN}, and \var{arg}
Fred Drake3adf79e2001-10-12 19:01:43 +0000754 depends on the value of \var{what}:
755
756 \begin{tableii}{l|l}{constant}{Value of \var{what}}{Meaning of \var{arg}}
757 \lineii{PyTrace_CALL}{Always \NULL.}
Nicholas Bastinc69ebe82004-03-24 21:57:10 +0000758 \lineii{PyTrace_EXCEPTION}{Exception information as returned by
Fred Drake3adf79e2001-10-12 19:01:43 +0000759 \function{sys.exc_info()}.}
760 \lineii{PyTrace_LINE}{Always \NULL.}
761 \lineii{PyTrace_RETURN}{Value being returned to the caller.}
Nicholas Bastinc69ebe82004-03-24 21:57:10 +0000762 \lineii{PyTrace_C_CALL}{Name of function being called.}
763 \lineii{PyTrace_C_EXCEPTION}{Always \NULL.}
764 \lineii{PyTrace_C_RETURN}{Always \NULL.}
Fred Drake3adf79e2001-10-12 19:01:43 +0000765 \end{tableii}
766\end{ctypedesc}
767
768\begin{cvardesc}{int}{PyTrace_CALL}
769 The value of the \var{what} parameter to a \ctype{Py_tracefunc}
770 function when a new call to a function or method is being reported,
771 or a new entry into a generator. Note that the creation of the
772 iterator for a generator function is not reported as there is no
773 control transfer to the Python bytecode in the corresponding frame.
774\end{cvardesc}
775
Nicholas Bastinc69ebe82004-03-24 21:57:10 +0000776\begin{cvardesc}{int}{PyTrace_EXCEPTION}
Fred Drake3adf79e2001-10-12 19:01:43 +0000777 The value of the \var{what} parameter to a \ctype{Py_tracefunc}
Fred Drake5bf1ecd2001-10-16 19:23:55 +0000778 function when an exception has been raised. The callback function
779 is called with this value for \var{what} when after any bytecode is
780 processed after which the exception becomes set within the frame
Martin v. Löwis95cf84a2003-10-19 07:32:24 +0000781 being executed. The effect of this is that as exception propagation
Fred Drake5bf1ecd2001-10-16 19:23:55 +0000782 causes the Python stack to unwind, the callback is called upon
Thomas Helleread60e52002-12-06 22:42:13 +0000783 return to each frame as the exception propagates. Only trace
Fred Drake5bf1ecd2001-10-16 19:23:55 +0000784 functions receives these events; they are not needed by the
785 profiler.
Fred Drake3adf79e2001-10-12 19:01:43 +0000786\end{cvardesc}
787
788\begin{cvardesc}{int}{PyTrace_LINE}
789 The value passed as the \var{what} parameter to a trace function
790 (but not a profiling function) when a line-number event is being
791 reported.
792\end{cvardesc}
793
794\begin{cvardesc}{int}{PyTrace_RETURN}
795 The value for the \var{what} parameter to \ctype{Py_tracefunc}
Martin v. Löwis95cf84a2003-10-19 07:32:24 +0000796 functions when a call is returning without propagating an exception.
Fred Drake3adf79e2001-10-12 19:01:43 +0000797\end{cvardesc}
798
Nicholas Bastinc69ebe82004-03-24 21:57:10 +0000799\begin{cvardesc}{int}{PyTrace_C_CALL}
800 The value for the \var{what} parameter to \ctype{Py_tracefunc}
801 functions when a C function is about to be called.
802\end{cvardesc}
803
804\begin{cvardesc}{int}{PyTrace_C_EXCEPTION}
805 The value for the \var{what} parameter to \ctype{Py_tracefunc}
806 functions when a C function has thrown an exception.
807\end{cvardesc}
808
809\begin{cvardesc}{int}{PyTrace_C_RETURN}
810 The value for the \var{what} parameter to \ctype{Py_tracefunc}
811 functions when a C function has returned.
812\end{cvardesc}
813
Fred Drake3adf79e2001-10-12 19:01:43 +0000814\begin{cfuncdesc}{void}{PyEval_SetProfile}{Py_tracefunc func, PyObject *obj}
815 Set the profiler function to \var{func}. The \var{obj} parameter is
816 passed to the function as its first parameter, and may be any Python
817 object, or \NULL. If the profile function needs to maintain state,
818 using a different value for \var{obj} for each thread provides a
819 convenient and thread-safe place to store it. The profile function
820 is called for all monitored events except the line-number events.
821\end{cfuncdesc}
822
823\begin{cfuncdesc}{void}{PyEval_SetTrace}{Py_tracefunc func, PyObject *obj}
Raymond Hettingerf17d65d2003-08-12 00:01:16 +0000824 Set the tracing function to \var{func}. This is similar to
Fred Drake3adf79e2001-10-12 19:01:43 +0000825 \cfunction{PyEval_SetProfile()}, except the tracing function does
826 receive line-number events.
827\end{cfuncdesc}
828
829
830\section{Advanced Debugger Support \label{advanced-debugging}}
831\sectionauthor{Fred L. Drake, Jr.}{fdrake@acm.org}
832
833These functions are only intended to be used by advanced debugging
834tools.
835
836\begin{cfuncdesc}{PyInterpreterState*}{PyInterpreterState_Head}{}
837 Return the interpreter state object at the head of the list of all
838 such objects.
839 \versionadded{2.2}
840\end{cfuncdesc}
841
842\begin{cfuncdesc}{PyInterpreterState*}{PyInterpreterState_Next}{PyInterpreterState *interp}
843 Return the next interpreter state object after \var{interp} from the
844 list of all such objects.
845 \versionadded{2.2}
846\end{cfuncdesc}
847
848\begin{cfuncdesc}{PyThreadState *}{PyInterpreterState_ThreadHead}{PyInterpreterState *interp}
849 Return the a pointer to the first \ctype{PyThreadState} object in
850 the list of threads associated with the interpreter \var{interp}.
851 \versionadded{2.2}
852\end{cfuncdesc}
853
854\begin{cfuncdesc}{PyThreadState*}{PyThreadState_Next}{PyThreadState *tstate}
855 Return the next thread state object after \var{tstate} from the list
856 of all such objects belonging to the same \ctype{PyInterpreterState}
857 object.
858 \versionadded{2.2}
859\end{cfuncdesc}