1. 24 May, 2017 1 kayıt (commit)
  2. 23 May, 2017 14 kayıt (commit)
  3. 22 May, 2017 10 kayıt (commit)
  4. 21 May, 2017 2 kayıt (commit)
  5. 20 May, 2017 4 kayıt (commit)
  6. 19 May, 2017 3 kayıt (commit)
  7. 18 May, 2017 4 kayıt (commit)
  8. 17 May, 2017 2 kayıt (commit)
    • Louie Lu's avatar
      ba365da9
    • Nathaniel J. Smith's avatar
      bpo-30039: Don't run signal handlers while resuming a yield from stack (#1081) · ab4413a7
      Nathaniel J. Smith yazdı
      If we have a chain of generators/coroutines that are 'yield from'ing
      each other, then resuming the stack works like:
      
      - call send() on the outermost generator
      - this enters _PyEval_EvalFrameDefault, which re-executes the
        YIELD_FROM opcode
      - which calls send() on the next generator
      - which enters _PyEval_EvalFrameDefault, which re-executes the
        YIELD_FROM opcode
      - ...etc.
      
      However, every time we enter _PyEval_EvalFrameDefault, the first thing
      we do is to check for pending signals, and if there are any then we
      run the signal handler. And if it raises an exception, then we
      immediately propagate that exception *instead* of starting to execute
      bytecode. This means that e.g. a SIGINT at the wrong moment can "break
      the chain" – it can be raised in the middle of our yield from chain,
      with the bottom part of the stack abandoned for the garbage collector.
      
      The fix is pretty simple: there's already a special case in
      _PyEval_EvalFrameEx where it skips running signal handlers if the next
      opcode is SETUP_FINALLY. (I don't see how this accomplishes anything
      useful, but that's another story.) If we extend this check to also
      skip running signal handlers when the next opcode is YIELD_FROM, then
      that closes the hole – now the exception can only be raised at the
      innermost stack frame.
      
      This shouldn't have any performance implications, because the opcode
      check happens inside the "slow path" after we've already determined
      that there's a pending signal or something similar for us to process;
      the vast majority of the time this isn't true and the new check
      doesn't run at all.
      ab4413a7