1. 20 May, 2017 4 kayıt (commit)
  2. 19 May, 2017 3 kayıt (commit)
  3. 18 May, 2017 4 kayıt (commit)
  4. 17 May, 2017 7 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
    • Steve Dower's avatar
    • Steve Dower's avatar
      Adds lib.pyproj file to solution (#1633) · 78e25ab5
      Steve Dower yazdı
      * Adds lib.pyproj file to solution so that VS with Python support can open all the files in the standard library.
      
      * Remove unexpected solution configuration.
      
      * Remove lib.pyproj from solution to avoid memory issues on VS 2015.
      78e25ab5
    • Dong-hee Na's avatar
    • Victor Stinner's avatar
      bpo-30387: Fix warning in test_threading (#1634) · f8d05b3a
      Victor Stinner yazdı
      test_is_alive_after_fork() now joins directly the thread to avoid the
      following warning added by bpo-30357:
      
      Warning -- threading_cleanup() failed to cleanup 0 threads
      after 2 sec (count: 0, dangling: 21)
      
      Use also a different exit code to catch generic exit code 1.
      f8d05b3a
    • Xiang Zhang's avatar
      bpo-30301: Fix AttributeError when using SimpleQueue.empty() (#1601) · 6f75bc00
      Xiang Zhang yazdı
      Under  *spawn* and *forkserver* start methods, SimpleQueue.empty() could
      raise AttributeError due to not setting _poll in __setstate__.
      6f75bc00
  5. 16 May, 2017 9 kayıt (commit)
  6. 15 May, 2017 10 kayıt (commit)
  7. 14 May, 2017 3 kayıt (commit)