Passlib is pure python, and doesn't deal directly with GIL (or any of the CPython API). So the only places it should block are when it calls into a C extension...
Calls to stdlib's hashlib -- Pretty much all of passlib's algorithms make LOTS of calls to hashlib. As of Python 2.7, hashlib supposedly releases the GIL when hashing large messages. But pretty much all passlib's calls have messages < the hash's internal block size; so while the GIL probably isn't released during those calls, they should be very quick, meaning calls to things like pbkdf2_sha256 should return to the VM quite frequently.
Calls to stdlib's crypt.crypt() -- This is used by default on POSIX systems for certain hashes, such as sha256_crypt. I'm not clear at all as to when / if stdlib releases the GIL while crypt.crypt() is going on... though that would certainly be helpful for longer-running ones such as sha256_crypt. If you're using sha256_crypt or any passlib algorithm that may use crypt.crypt(), you can make a call to ``sha256_crypt.set_backend("builtin")`` (or equivalent for the respective hash) to force passlib's pure-python version (which use hashlib).
Bcrypt -- Passlib's bcrypt hash relies on one of a two third-party C extensions provide the backend: py-bcrypt (
https://pypi.python.org/pypi/py-bcrypt) and bcrypt (
https://pypi.python.org/pypi/bcrypt). From your link, it looks like py-bcrypt releases the GIL. The other one, bcrypt, is CFFI-based and the CFFI docs indicate all CFFI calls are made without the GIL; so both those options should be safe.
Outside of that, there shouldn't be anything holding the GIL or any other thread locks.