Call sigsetjmp/siglongjmp directly in code #237
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This lets us control when we do want to save the signal mask (i.e., when
longjmping out of the signal handler) or don't (i.e., whenever we're just doing exceptions).It's a bit more explicit, which is nice, given the "function X is actually slightly-different function Y" macrology can be confusing (I've been bitten by it in the past).
There's also a minor but possibly non-negligible performance benefit, since it makes the most common case,
setjmpcalls as part ofExceptionHandlermacros, ~100x faster by cutting out a couple syscalls for eachsetjmp(). This is a relatively tiny benefit, but givenExceptionHandleris called for every$&parse,$&here, redirection, lambda evaluation, every time a dynamically-scoped variable is popped, twice for each$&catch, and more, it seems reasonable to make this pretty tiny and simple optimization. If #73 or something similar ever gets merged such thatifand<=also catch certain exceptions, then this would help even more.