Skip to content
  1. Aug 19, 2015
  2. Aug 18, 2015
  3. Aug 17, 2015
  4. Aug 16, 2015
  5. Aug 13, 2015
  6. Aug 11, 2015
  7. Aug 10, 2015
  8. Aug 09, 2015
  9. Aug 07, 2015
  10. Aug 06, 2015
    • Jesse Glick's avatar
      arbitrary change · 9bcd351e
      Jesse Glick authored
      9bcd351e
    • Jesse Glick's avatar
    • Stephen Connolly's avatar
      [FIXES #1777] Make accessing pendingLaunches lock free · 030793f0
      Stephen Connolly authored
      - My objection to #1777 is that it is introducing more locking. The ultimate aim is to make
        node provisioning and queue maintenance completely lock free. Thus adding more locks than
        is strictly required is a bad plan.
      - We cannot completely remove provisioningLock at this time as it is used to ensure that
        only one provisioning activity can take place for a given label at a time.
      - This change ensures that the provisioningLock is only used by the NodeProvisioner for
        its internal thread guarantees and is thus no-longer used accidentally by any
        external threads
      030793f0
    • Daniel Beck's avatar
      1.623 has no notable changes · a798aa42
      Daniel Beck authored
      a798aa42
    • Stephen Connolly's avatar
      [JENKINS-28690] Aha! So I believe this will fully resolve any of these kinds of deadlocks · 0ba505b6
      Stephen Connolly authored
      - Without this, then it becomes a question of find catch and release for each potential code path that
        might end up restoring the interrupt flag on the current thread.
      - Since standard Lock support is kind enough to restore the interrupt flag on the current thread
        when blocked waiting for the lock, that would be a hiding to nothing
      - I welcome others to review my logic detailed in the code comment
      - I am leaving the code comment as this is IMHO too important to assume that somebody will
        check the git commit history
      0ba505b6
  11. Aug 05, 2015
Loading