Matt Bandy added the comment:
Sorry, I should have been more precise. I did use static for the variable I
declared at file scope. Looking at the disassembly again also reminded me of
something I should have mentioned in the original bug report: at least when
using Visual C++ 2008, in the
Matt Bandy added the comment:
I tried this out in VC++ 2008 with the new temporary as both a global variable
and a local. At least for VC++, Amaury is correct -- the compiler is
generating the store to the global even though it is never read, so making it a
local instead does save an
Matt Bandy added the comment:
That should probably be:
#define Py_ADDRESS_IN_RANGE(P, POOL)\
((x = (POOL)->arenaindex) < maxarenas &&\
(uptr)(P) - arenas[x].address < (uptr)ARENA_SIZE && \
arenas[x].address
Matt Bandy added the comment:
It's a pretty major limitation on the embedding case if you can't allow other
threads that aren't related to Python to run at any time that another thread
may be in obmalloc, and one I haven't seen documented anywhere. The only other
fix tha
Matt Bandy added the comment:
Amaury is correct -- in the case I observed, the other thread had nothing to do
with Python and was not calling Python functions that would have required
obtaining the GIL at any time (again, I'm using an embedded Python interpreter
in a larger app, no
Matt Bandy added the comment:
You can't add a block without changing the way the macro is used -- it's
usually used like:
if (Py_ADDRESS_IN_RANGE(p, pool))
This won't work with your proposed change since you can't put a do {} loop into
the test expression
New submission from Matt Bandy :
Using the Py_ADDRESS_IN_RANGE macro can result in a crash under certain
threading conditions. Since it is intentionally possible for
(POOL)->arenaindex to reference memory which is not under Python's control,
another thread may modify that mem
