A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-December/106911.html below:

[Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable

[Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable"Martin v. Löwis" martin at v.loewis.de
Mon Dec 20 08:22:40 CET 2010
>> Looking at your function list, my other concern is that you are calling
>> Python API without holding the GIL, IIUC. In particular, you are
>> accessing _PyThreadState_Current, which may not point to the current
>> thread if the current thread has released the GIL.
> 
> Ah? Where does _PyThreadState_Current point to if the GIL is not hold
> when the fault handler is called?

The GIL is likely held by a different thread, then.
_PyThreadState_Current will point to the state of this other thread.

> It looks that _PyThreadState_Current can be NULL if the GIL is released.
> In this case, _Py_DumpBacktrace() just do nothing. There is also a
> gil_last_holder variable: can it be used to get the thread state
> (especially if the thread state was deleted)?

Of this thread? I don't think so. gil_last_holder might also refer to
a different thread.

> I don't think that it will possible the acquire the GIL in
> Py_FatalError() or in the fault handler.

I agree.

Regards,
Martin
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4