summaryrefslogtreecommitdiffstats
path: root/Python/pystate.c
Commit message (Collapse)AuthorAgeFilesLines
* revert tstate_delete_common, since it's pretty much wrongBenjamin Peterson2014-06-171-8/+1
|
* avoid a deadlock with the interpreter head lock and the GIL during finalizationBenjamin Peterson2014-06-171-1/+8
|
* Issue #13992: The trashcan mechanism is now thread-safe. This eliminatesAntoine Pitrou2012-09-051-0/+3
| | | | | | | | | | | sporadic crashes in multi-thread programs when several long deallocator chains ran concurrently and involved subclasses of built-in container types. Because of this change, a couple extension modules compiled for 2.7.4 (those which use the trashcan mechanism, despite it being undocumented) will not be loadable by 2.7.3 and earlier. However, extension modules compiled for 2.7.3 and earlier will be loadable by 2.7.4.
* move outside WITH_THREAD conditionalBenjamin Peterson2012-04-131-2/+2
|
* take linkage def outside of WITH_THREAD conditional (closes #14569)Benjamin Peterson2012-04-131-4/+3
|
* Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for nativeCharles-François Natali2011-10-121-17/+0
| | | | | | TLS implementations, and fails with the ad-hoc TLS implementation when a thread doesn't have an auto thread state (e.g. a thread created outside of Python calling into a subinterpreter).
* Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_*Antoine Pitrou2011-04-271-0/+17
| | | | | APIs, to avoid a crash with the pthread implementation in RHEL 5. Patch by Charles-François Natali.
* #11565: Fix several typos. Patch by Piotr Kasprzyk.Ezio Melotti2011-03-161-1/+1
|
* Merged revisions 84623 via svnmerge fromAntoine Pitrou2010-09-081-8/+7
| | | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/branches/py3k ........ r84623 | antoine.pitrou | 2010-09-08 14:37:10 +0200 (mer., 08 sept. 2010) | 4 lines Issue #9797: pystate.c wrongly assumed that zero couldn't be a valid thread-local storage key. ........
* Untabify C files. Will watch buildbots.Antoine Pitrou2010-05-091-361/+361
|
* Issue #7544: Preallocate thread memory before creating the thread to avoid aVictor Stinner2010-03-031-5/+23
| | | | fatal error in low memory condition.
* Adds a sanity check to avoid a *very rare* infinite loop due to a corrupt tlsGregory P. Smith2008-08-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | key list data structure in the thread startup path. This change is a companion to r60148 which already successfully dealt with a similar issue on thread shutdown. In particular this loop has been observed happening from this call path: #0 in find_key () #1 in PyThread_set_key_value () #2 in _PyGILState_NoteThreadState () #3 in PyThreadState_New () #4 in t_bootstrap () #5 in pthread_start_thread () I don't know how this happens but it does, *very* rarely. On more than one hardware platform. I have not been able to reproduce it manually. (A flaky mutex implementation on the system in question is one hypothesis). As with r60148, the spinning we managed to observe in the wild was due to a single list element pointing back upon itself.
* Provide a sanity check during PyThreadState_DeleteCurrent() andGregory P. Smith2008-01-211-0/+10
| | | | | | | | | | | | | | PyThreadState_Delete() to avoid an infinite loop when the tstate list is messed up and has somehow becomes circular and does not contain the current thread. I don't know how this happens but it does, *very* rarely. On more than one hardware platform. I have not been able to reproduce it manually. Attaching to a process where its happening: it has always been in an infinite loop over a single element tstate list that is not the tstate we're looking to delete. It has been in t_bootstrap()'s call to PyThreadState_DeleteCurrent() as a pthread is exiting.
* Bug #742342: make Python stop segfaulting on infinitely-recursive reload()s. ↵Collin Winter2007-03-121-0/+2
| | | | | | Fixed by patch #922167. Will backport.
* Remove extra semi-colons reported by Johnny Lee on python-dev. Backport if ↵Neal Norwitz2006-09-231-1/+1
| | | | anyone cares.
* Forward-port of rev. 51857:Georg Brandl2006-09-111-1/+6
| | | | | | | | | | | Building with HP's cc on HP-UX turned up a couple of problems. _PyGILState_NoteThreadState was declared as static inconsistently. Make it static as it's not necessary outside of this module. Some tests failed because errno was reset to 0. (I think the tests that failed were at least: test_fcntl and test_mailbox). Ensure that errno doesn't change after a call to Py_END_ALLOW_THREADS. This only affected debug builds.
* Followup to bug #1069160.Tim Peters2006-08-101-12/+27
| | | | | | PyThreadState_SetAsyncExc(): internal correctness changes wrt refcount safety and deadlock avoidance. Also added a basic test case (relying on ctypes) and repaired the docs.
* Handle allocation failures gracefully. Found with failmalloc.Neal Norwitz2006-07-211-0/+4
| | | | Many (all?) of these could be backported.
* SF bug 1524317: configure --without-threads fails to buildTim Peters2006-07-191-48/+47
| | | | | | | | | | | | | | | | | | Moved the code for _PyThread_CurrentFrames() up, so it's no longer in a huge "#ifdef WITH_THREAD" block (I didn't realize it /was/ in one). Changed test_sys's test_current_frames() so it passes with or without thread supported compiled in. Note that test_sys fails when Python is compiled without threads, but for an unrelated reason (the old test_exit() fails with an indirect ImportError on the `thread` module). There are also other unrelated compilation failures without threads, in extension modules (like ctypes); at least the core compiles again. Do we really support --without-threads? If so, there are several problems remaining.
* After approval from Anthony, merge the tim-current_framesTim Peters2006-07-101-3/+51
| | | | | | branch into the trunk. This adds a new sys._current_frames() function, which returns a dict mapping thread id to topmost thread stack frame.
* Zap ZAP.Martin v. Löwis2006-04-151-25/+18
|
* spread the extern "C" { } magic pixie dust around. Python itself builds nowAnthony Baxter2006-04-131-0/+11
| | | | | using a C++ compiler. Still lots and lots of errors in the modules built by setup.py, and a bunch of warnings from g++ in the core.
* more low-hanging fruit to make code compile under a C++ compiler. NotAnthony Baxter2006-04-111-8/+9
| | | | | entirely happy with the two new VISIT macros in compile.c, but I couldn't see a better approach.
* Patch 1413181, by Gabriel Becedillas.Tim Peters2006-02-271-0/+4
| | | | | | | | | PyThreadState_Delete(): if the auto-GIL-state machinery knows about the thread state, forget it (since the thread state is being deleted, continuing to remember it can't help, but can hurt if another thread happens to get created with the same thread id). I'll backport to 2.4 next.
* Forward port bugfix:Michael W. Hudson2005-09-301-0/+4
| | | | | | [ 1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code) (note that this only happens in a threads-disabled build).
* Fix bug:Michael W. Hudson2005-06-201-15/+53
| | | | | | | | [ 1163563 ] Sub threads execute in restricted mode basically by fixing bug 1010677 in a non-broken way. Backport candidate.
* You can have more than one thread state for a thread if theyMichael W. Hudson2005-06-161-1/+1
| | | | | correspond to different interpreters (I hope, please revert if this is wrong :).
* Fix:Michael W. Hudson2005-04-181-1/+1
| | | | | | | | [ 1176893 ] Readline segfault by unsilly-ing PyGILState_Release(). Backport candidate.
* Close the discussion in SF bug 1069160.Guido van Rossum2005-02-081-1/+3
|
* SF bug 1061968: threads: segfault or Py_FatalError at exitTim Peters2004-11-081-13/+12
| | | | | | | | | | | | | | | | | PyGILState_Ensure(): The fix in 2.4a3 for bug 1010677 reintroduced thread shutdown race bug 225673. Repaired by (once again) ensuring the GIL is held whenever deleting a thread state. Alas, there's no useful test case for this shy bug. Four years ago, only Guido could provoke it, on his box, and today only Armin can provoke it on his box. I've never been able to provoke it (but not for lack of trying!). This is a critical fix for 2.3.5 too, since the fix for 1010677 got backported there already and so also reintroduced 225673. I don't intend to backport this fix. For whoever (if anyone) does, there are other thread fixes in 2.4 that need backporting too, and I bet they need to happen first for this patch to apply cleanly.
* Revert rev 2.35. It was based on erroneous reasoning -- the currentTim Peters2004-10-101-15/+8
| | | | | | | thread's id can't get duplicated, because (of course!) the current thread is still running. The code should work either way, but reverting the gratuitous change should make backporting easier, and gets the bad reasoning out of 2.35's new comments.
* PyInterpreterState_New(), PyThreadState_New(): use malloc/free directly.Tim Peters2004-10-101-4/+16
| | | | | | This appears to finish repairs for SF bug 1041645. This is a critical bugfix.
* PyGILState_Release(): If we need to delete the TLS entry for this thread,Tim Peters2004-10-091-8/+15
| | | | | that must be done under protection of the GIL, for reasons explained in new comments.
* _PyGILState_Init(), PyGILState_Ensure(): Since PyThread_set_key_value()Tim Peters2004-10-091-2/+5
| | | | | | | | | can fail, check its return value, and die if it does fail. _PyGILState_Init(): Assert that the thread doesn't already have an association for autoTLSkey. If it does, PyThread_set_key_value() will ignore the attempt to (re)set the association, which the code clearly doesn't want.
* Style guide & consistency changes. No semantic changes.Tim Peters2004-10-091-23/+29
|
* Trim trailing whitespace.Tim Peters2004-10-091-8/+8
|
* Patch #510695: Add TSC profiling for the VM.Martin v. Löwis2004-06-081-0/+3
|
* Changed random calls to PyThreadState_Get() to use the macroNicholas Bastin2004-03-241-1/+1
|
* Initialize thread_id to 0 in unthreaded build. Fixes #770247.Martin v. Löwis2003-07-131-0/+4
|
* Add PyThreadState_SetAsyncExc(long, PyObject *).Guido van Rossum2003-06-281-0/+30
| | | | | | | | | A new API (only accessible from C) to interrupt a thread by sending it an exception. This is not always effective, but might help some people. Requested by Just van Rossum and Alex Martelli. It is intentional that you have to write your own C extension to call it from Python. Docs will have to wait.
* Patch #729300: Disable error message if Python is not built for threads.Martin v. Löwis2003-05-011-1/+1
|
* New PyGILState_ API - implements pep 311, from patch 684256.Mark Hammond2003-04-191-1/+140
|
* - pythunrun.c, Py_Finalize(): move the call to _Py_PrintReferences()Guido van Rossum2003-04-151-5/+9
| | | | | | | | | | | | | | | | | | | even farther down, to just before the call to _PyObject_DebugMallocStats(). This required the following changes: - pystate.c, PyThreadState_GetDict(): changed not to raise an exception or issue a fatal error when no current thread state is available, but simply return NULL without raising an exception (ever). - object.c, Py_ReprEnter(): when PyThreadState_GetDict() returns NULL, don't raise an exception but return 0. This means that when printing a container that's recursive, printing will go on and on and on. But that shouldn't happen in the case we care about (see first bullet). - Updated Misc/NEWS and Doc/api/init.tex to reflect changes to PyThreadState_GetDict() definition.
* Fixed SF bug #663074. The codec system was using global staticGustavo Niemeyer2003-03-191-0/+6
| | | | | | | | | variables to store internal data. As a result, any atempts to use the unicode system with multiple active interpreters, or successive interpreter executions, would fail. Now that information is stored into members of the PyInterpreterState structure.
* - PyEval_GetFrame() is now declared to return a PyFrameObject *Guido van Rossum2003-02-191-2/+2
| | | | instead of a plain PyObject *. (SF patch #686601 by Ben Laurie.)
* Assorted patches from Armin Rigo:Michael W. Hudson2002-11-081-0/+11
| | | | | | | | [ 617309 ] getframe hook (Psyco #1) [ 617311 ] Tiny profiling info (Psyco #2) [ 617312 ] debugger-controlled jumps (Psyco #3) These are forward ports from 2.2.2.
* missed this one on the previous multi-file checkin - seeSkip Montanaro2002-09-031-2/+0
| | | | http://python.org/sf/602191
* Add a low-level API to access interpreters, for David Beazley.Guido van Rossum2001-07-191-0/+25
| | | | SF patch #436376.
* Patch #412229: Add functions sys.getdlopenflags and sys.setdlopenflags.Martin v. Löwis2001-07-181-0/+17
| | | | Add dlopenflags to PyInterpreterState, and use it in dlopen calls.
* This change adjusts the profiling/tracing support so that the commonFred Drake2001-07-031-0/+1
| | | | | | | | | | | | | | | | path (with no profile/trace function) through eval_code2() and eval_frame() avoids several checks. In the common cases of calls, returns, and exception propogation, eval_code2() and eval_frame() used to test two values in the thread-state: the profiling function and the tracing function. With this change, a flag is set in the thread-state if either of these is active, allowing a single check to suffice when both are NULL. This also simplifies the code needed when either function is in use but is already active (to avoid profiling/tracing the profiler/tracer); the flag is set to 0 when the profile/trace code is entered, allowing the same check to suffice for "already in the tracer" for call/return/ exception events.