Commits on Nov 12, 2017

1. Change CallbackGuard to require explicit destruction …

   This commit alters the API of the `CallbackGuard` in a semver-breaking
   way. Previously the guard would abort the process if the current thread
   were panicking when it was dropped. After this change, however, the
   `thread::panicking` function isn't used and instead an explicit call to
   destruction is required. If a `CallbackGuard` is dropped "normally" (aka
   the compiler auto-drops it) then that likely indicates a panic (or a
   bug) and the process will be aborted.
   
   This tweak brings with it a few benefits:
   
   * LLVM can optimize this much better as it can infer that a chunk of
     code between the creation of a guard and its drop doesn't panic.
     Previously it would not optimize away creation/dropping the guard but
     after this change LLVM should be able to optimize this away. Put
     another way, after this commit LLVM can optimize away usage of
     `CallbackGuard` if it can prove the code won't panic.
   
   * Runtime-wise this should be a bit cheaper on the "fast path" as
     checking `thread::panicking` requires... well... at least a function
     call! By calling `defuse` though it's a noop at runtime which means
     that no extra code happens on the fast path when a panic doens't
     happen.
   
   * Finally, a slightly more esoteric benefit, but if a thread is
     panicking *already* and during a destructor some glib calls were made,
     this strategy will no longer abort the process. Ideally the callback
     guard only aborts the process if the state of the thread panicking
     *changes* rather than only is true on exit. This is likely to only
     come up pretty rarely, though!

   

   alexcrichton committed Nov 12, 2017
   Configuration menu

   • View commit details
   • Copy full SHA for ec29a0f
   • Browse repository at this point

   Copy the full SHA

   ec29a0f View commit details

   Browse the repository at this point in the history