Thread State and the Global Interpreter Lock:
The lock is also released around potentially blocking I/O operations like reading or writing a file, so that other Python threads can run in the meantime.
A related answer here by @Alex Martelli says:
All of Python's blocking I/O primitives release the GIL while waiting for the I/O block to resolve -- it's as simple as that! They will of course need to acquire the GIL again before going on to execute further Python code, but for the long-in-terms-of-machine-cycles intervals in which they're just waiting for some I/O syscall, they don't need the GIL, so they don't hold on to it!
*Does this mean when open
or read
or write
happened to be blocking, the GIL is released so other threads run in parallel to the I/O operation?
Is it right to say then: there could possibly be multiple threads executing at the same time given one thread or more threads are blocked by an I/O operation and there would be only one single thread executing bytes codes. Whenever one of the blocked threads by the I/O operation needs to access Python objects it has to acquire the GIL first.