Currently, the caveats section of the thread/_thread module has this statement in it: "Not all built-in functions that may block waiting for I/O allow other threads to run. (The most popular ones (time.sleep(), file.read(), select.select()) work as expected.)" As far as I know, this isn't the case; all built-in functions that do blocking I/O release the GIL, and therefore do indeed allow other threads to run. I asked a question about this on stackoverflow recently (http://stackoverflow.com/q/24831458/2073595), and Mark Dickinson helpfully pointed out that this statement was added by Guido way back in 1994, which suggests it's probably just obsolete. If that's the case, the statement should be removed to avoid confusion.
It seems likely that this information is just out of date. But even if there *are* still built-in functions lurking somewhere that don't release the GIL during I/O, the statement in the docs isn't really helpful in finding them. Either way, I'd recommend simply removing it. Adding Guido to the nosy in case he can provide a pre-Python 1.0 historical perspective.
It all depends what you call "I/O". What is true is that not all functions doing system calls release the GIL, AFAIR. If you mean I/O as in actual disk or network I/O then yes, all such functions whould release the GIL. That said, I agree that the statement isn't very helpful.
title: thread module documentation erroneously(?) states not all built-in functions release the GIL -> thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL
