FIX memoryview leaks and retrofit memory-manager as context-managers

[ankostis]

BREAKING API:

• retrofit git.util.mman as context-manager, to release memory-mapped regions held.

  The mmap-manager(s) are re-entrant, but not thread-safe context-manager(s), to be used within a with ...: block, ensuring any left-overs cursors are cleaned up. If not entered, :meth:StaticWindowMapManager.make_cursor() and/or :meth:WindowCursor.use_region() will scream.

  Get them from smmap.managed_mmaps().

• Simplify :class:SlidingWindowMapBuffer as create/close context-manager (no begin_access(), or end_access()).

[coveralls]

Coverage decreased (-0.7%) to 93.116% when pulling 144891bc6c3d5ecdd96e522cb4e3571dff948171 on ankostis:leaks2 into 6e55a1c70843e5e5e29686176325f309f8285f29 on gitpython-developers:master.

[coveralls]

Coverage decreased (-0.7%) to 93.116% when pulling 144891bc6c3d5ecdd96e522cb4e3571dff948171 on ankostis:leaks2 into 6e55a1c70843e5e5e29686176325f309f8285f29 on gitpython-developers:master.

[ankostis]

@byron can you check these lines where a memoryview is crated?

It took me the half month to realize that this is leaking badly, and I want you to check the history of this commits leading up to it, because I cannot understand whether they were mistake or intentional, and what would be the repercussions (ie, performance?).

[Byron]

@ankostis Sorry for the very late reply. I am no holiday now, and am working through everything that piled up. About the matter: I don't understand why this would leak in the first place. Does that mean it's a python 3 only issue? Also I wonder how anything can leak in the first place unless there are dependency cycles. The comment in the respective are of the code also contains an alternative. It appears that it was chosen just for performance reasons. Maybe alternatives do by now exist too.

[ankostis]

Yes, it is a python-3 issue, because the destructors are not deterministic. Untill all memoryview for some mmemp have close, neither the memmap nor its file can be collected.

Now, in python3, you can slice memmaps as if they were memoryview, so they are not strictly needed, unless it is a performance issue. From some quick experiments I had done, I could not see any benefits, quite the contrary, but it's been a long time and I don't remember exactly.

[Byron]

If using direct access would be a solution, then it probably should be used instead. Correctness over performance I would say. The main driver behind using the 'buffer' interface was to prevent copying of the slices that are read, and thus maintain the awesome properties of a memory map even in python. I do remember me digging around in python source code to see if copies were made. However, now is a different time, and slicing memory maps directly in python 3 sounds appealing to me.