don't release the GIL

[esc]

No description provided.

[esc]

@FrancescAlted seems too easy somehow.

[FrancescAlted]

@ThomasWaldmann If what you are asking is why we are holding the GIL now is because the new c-blosc 1.5 series does not have a global lock anymore, so it is up to the application to provide it. In Python the cheapest way is to leverage the GIL so that it will prevent multithreaded Python apps to step on each other and corrupt c-blosc internal variables.

[FrancescAlted]

Merging. With that, I think it is safe to include the recently released c-blosc 1.5.3. As you know, I would like to have this in (instead of 1.4 series) so as to get more feedback on whether the issues in bcolz and 1.5 series is a problem with c-blosc, bcolz or another reason (GCC, libc...).

[ThomasWaldmann]

Ah, so it's basically similar as before, just done at another place.
It looked like you were not holding a lock before and would hold one after the changeset.

[FrancescAlted]

Yes, holding the GIL is the intent.

[esc]

Thanks for the merge, I'll get a PR ready for Blosc v1.5.3

[esc]

@ThomasWaldmann we also recently had a discussion about this over at bcolz: Blosc/bcolz#166

[ThomasWaldmann]

I just wrote some multithreaded code for attic / borg backup. If blosc could work flawlessly without holding the GIL, I guess I would get some better parallelism (it does I/O [no GIL issue], hashing [?], compression [blosc->GIL, zlib->?], encryption [?]).

[esc]

You can always try and see how it works for you. Older versions of Python-Blosc still had code that keept the GIL and worked well. you should check the changelog and find a version that included Blosc 1.4.x that was the last version that worked with releasing the GIL.

[ThomasWaldmann]

@esc ah, thanks for the hint!