4 ms·

Can you go into more detail about the right way to handle EINTR? When I wrote a server I wound up using the "if at first you get EINTR'd, try, try again".

• saurik 15y ago
  I'm not entirely certain at what level you are asking, but if I understand your question: yes, "try, try again". There are some legitimate reasons why you might want to "handle" an EINTR (such as for canceling threads), but honestly they are super-advanced usage (and normally something abstracted by your threading library): 99.9999% of the time you called a blocking function, knew it might block, and intended it to block until it did something. The problem with Python was that it was not retrying: it would just throw an EINTR i/o exception from its lowest-level read() bridge, and then most of the code that called that would not catch the exception. The result would be that you'd make an HTTP request and the top-level GET call would just throw "EINTR": it is not reasonable (or even semantically valid) to have to retry the entire HTTP request because a call to read() happened to fail while streaming the response. This was sufficiently ludicrous (and sufficiently simple to fix) that I had a patch I'd apply to Python's core libraries every time I installed or upgraded my system. ... and, before anyone tries to call me on "patch or GTFO": someone filed a bug, with a working patch (although people tried to quibble with it; I believe incorrectly, and it certainly didn't change the result), in January of 2007, and it wasn't resolved until mid-2010. I didn't come up with the fix: I just pulled it out of the bug tracker. http://bugs.python.org/issue1628205 http://bugs.python.org/issue1628205
  • endgame 15y ago
    Thanks for the history lesson and the thorough response. I'm going to sleep a little better tonight.