Message206080
| Author |
vstinner |
| Recipients |
Mark.Shannon, adamtj, asuffield, asvetlov, ncoghlan, neologix, pitrou, python-dev, rosslagerwall, scoder, serhiy.storchaka, vstinner |
| Date |
2013年12月13日.13:46:08 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CAMpsgwYX884dMxQZL+0=cUKySRxM8Xmww8arM4gEOm=b4a=r3w@mail.gmail.com> |
| In-reply-to |
<1386941693.29.0.344998656345.issue14432@psf.upfronthosting.co.za> |
| Content |
> Depends on how you use it, I guess. In many cases (at least for Cython and likely some other low-level tools), it could be as simple as
>
> #if PY_VERSION_HEX < 0x030400B2
> // set "f_tstate" here
> #endif
Why would you set f_tstate field? Frame constructor (PyFrame_New) and
Generators (gen_send_ex) do it for you.
Cython does touch this field? Stackless Python supports Python 3 (3.4)?
If something relies on f_tstate, it's easy to avoid this field.
> Would it be correct for them to just use the current thread state instead? E.g. from a signal handler that analysis the current threads?
The faulthandler has different low-level C signal handlers and it
doesn't use f_tstate, but PyGILState_GetThisThreadState() (or
PyThreadState_Get() if thread support is disabled).
I was surprised that it was so easy to modify ceval.c: in most cases,
you already have the thread state. So I just passed the thread state
to the function. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2013年12月13日 13:46:08 | vstinner | set | recipients:
+ vstinner, ncoghlan, pitrou, scoder, asvetlov, adamtj, neologix, Mark.Shannon, rosslagerwall, python-dev, serhiy.storchaka, asuffield |
| 2013年12月13日 13:46:08 | vstinner | link | issue14432 messages |
| 2013年12月13日 13:46:08 | vstinner | create |
|