summaryrefslogtreecommitdiffstats
path: root/Python/pystate.c
Commit message (Collapse)AuthorAgeFilesLines
* PyInterpreterState_New is not thread-safe, and the recent fix to _PyPcloseTim Peters2000-09-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | can cause it to get called by multiple threads simultaneously. Ditto for PyInterpreterState_Delete. Of the former, the docs say "The interpreter lock need not be held, but may be held if it is necessary to serialize calls to this function". This kinda implies it both is and isn't thread-safe. Of the latter, the docs merely say "The interpreter lock need not be held.", and the clause about serializing is absent. I expect it was *believed* these are both thread-safe, and the bit about serializing via the global lock was meant as a permission rather than a caution. I also expect we've never seen a problem here because the Python core (prior to the _PyPclose fix) only calls these functions once per run. The Py_NewInterpreter subsystem exposed by the C API (but not used by Python itself) also calls them, but that subsystem appears to be very rarely used. Whatever, they're both thread-safe now.
* REMOVED all CWI, CNRI and BeOpen copyright markings.Guido van Rossum2000-09-011-9/+0
| | | | This should match the situation in the 1.6b1 tree.
* Removing warnings by gcc -Wall -- cast ugly || to void.Moshe Zadka2000-08-041-1/+1
|
* Mass ANSIfication of function definitions. Doesn't cover all 'extern'Thomas Wouters2000-07-221-17/+10
| | | | declarations yet, those come later.
* Change copyright notice - 2nd try.Guido van Rossum2000-06-301-6/+0
|
* Change copyright notice.Guido van Rossum2000-06-301-22/+7
|
* CRITICAL PATCH!Guido van Rossum1999-06-181-5/+23
| | | | | | | | | | | | | | We occasionally received reports from people getting "invalid tstate" crashes (this is a fatal error in PyThreadState_Delete()). Finally several people were able to reproduce it reliably and Tim Peters discovered that there is a race condition when multiple threads are calling this function without holding the global interpreter lock (the function may be called without holding that). Solved the race condition by adding a lock around the mutating uses of interp->tstate_head. Tim and Jonathan Giddy have run tests that make it likely that this fixes the crashes -- although Tim hasn't heard from the person who reported the original problem.
* Make current_tstate a global, _PyThreadState_Current. This is toGuido van Rossum1998-12-211-10/+10
| | | | support a macro in pystate.h.
* /* An extension mechanism to store arbitrary additional per-thread state.Guido van Rossum1998-04-101-0/+21
| | | | | | | | | | PyThreadState_GetDict() returns a dictionary that can be used to hold such state; the caller should pick a unique key and store its state there. If PyThreadState_GetDict() returns NULL, an exception has been raised (most likely MemoryError) and the caller should pass on the exception. */ PyObject * PyThreadState_GetDict()
* The warning about thread still having a frame now only happens inGuido van Rossum1997-11-031-1/+1
| | | | verbose mode.
* Added missing newline to warning msgGuido van Rossum1997-08-211-1/+1
|
* The last of the mass checkins for separate (sub)interpreters.Guido van Rossum1997-08-021-26/+102
| | | | | | | Everything should now work again. See the comments for the .h files mass checkin (e.g. pystate.h) for more detail.
* Remove confusing usage comments at end.Guido van Rossum1997-07-191-28/+0
|
* Don't use function prototypes in function definition headers.Guido van Rossum1997-05-201-4/+8
|
* Massive changes for separate thread state management.Guido van Rossum1997-05-051-0/+163
All per-thread globals are moved into a struct which is manipulated separately.
generated by cgit v0.12 at 2024-12-01 20:47:26 (GMT)