greg.ath <gathan...@gmail.com> added the comment:
Hi,
I also wonder about the performance cost of a recursive lock.
I am still unable to reproduce the bug in a simple script. Looking
closely to the gdb stack, there is that frame:
Frame 0x13be190, for file /usr/lib/python2.6/multiprocessing/heap.py, line 173
I understand that python reuses only the beginning of a memory block,
so it frees the remaining of the block.
I use both Value(c_int) and Value(c_double), which have different
sizes. That may explain that behaviour.
in heap.py, in the malloc function:
167 self._lock.acquire()
168 try:
169 size = self._roundup(max(size,1), self._alignment)
170 (arena, start, stop) = self._malloc(size)
171 new_stop = start + size
172 if new_stop < stop:
173 self._free((arena, new_stop, stop))
Thanks for your help
2011/6/21 Charles-François Natali <rep...@bugs.python.org>:
>
> Charles-François Natali <neolo...@free.fr> added the comment:
>
>> The obvious solution is to use a recursive lock instead.
>
> Note that it's not really a solution, just a workaround to avoid
> deadlocks, become this might lead to a corruption if free is called
> while the heap is in an inconsistent state. I have to think some more
> about a final solution, but I'd like to check first that this is
> really what's happening here.
>
> ----------
>
> _______________________________________
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue12352>
> _______________________________________
>
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
