Larry Hastings added the comment:
Oy veh, in editing the issue I dropped the attached file. Here it is.
--
keywords: +patch
Added file:
http://bugs.python.org/file42479/larry.refresh.lock.macros.for.obmalloc.diff
___
Python tracker
Larry Hastings added the comment:
Patch attached. The basics were okay; however, there was no locking around
access to a static variable (_Py_AllocatedBlocks) so I added some. The way the
code managed _Py_AllocatedBlocks was a bit odd; this approach resulted in fewer
lines, but it was hard
Tim Peters added the comment:
Right, these macros were in the original module (by Vladimir Marangozov).
They've never done anything - never been tested. Over the years I removed
other layers of macro indirection (while other people added more ;-) ), but
left these alone because they point
Larry Hastings added the comment:
There's already a comment saying that the macros are empty because the GIL
protects obmalloc from parallelization.
I'd be happy to improve the code and add calls for LOCK_INIT and LOCK_FINI in
the proper places. You don't have to do it. Since this isn't
STINNER Victor added the comment:
These macros are very old, I didn't write them. They are not used since the
API rely on the GIL.
Do you want to remove them?
I think that it's ok to keep them, just in case, if tomorrow we want to
support multiple allocations in parallel. Maybe a comment
New submission from Larry Hastings:
Obmalloc now has theoretical support for locking. I say theoretical because
I'm not convinced it's ever been used.
The interface is defined through five macros:
SIMPLELOCK_DECL
SIMPLELOCK_INIT
SIMPLELOCK_FINI
SIMPLELOCK_LOCK
