The formatting cleanup is nice. I wouldn't complain if you made it a separate PR and put the rest of this on top after it goes in. There is still more cleanup to do, but I think others can take care of it.

Style changes in gh-16520 separately.
Will rebase once that's merged.

Rebased.

@pv IIRC, swapping was the main reason we could not use the newer interfaces that are in the include files. If you have any ideas for an public swap procedure I'd like to hear them.

@melissawm There are lots of opportunity for additional code beautification here, much of it whitespace :)

With C11 or C++11 we can use thread_local macro from the standard library, defined in threads.h. That will work on any standards compliant C or C++ compiler, even if The non-standard __thread and __declspec(thread) extensions are not defined.

Let's put this in, thanks Pauli. I'm a bit undecided on backporting, I'd rather keep changes to a minimum for the 1.19 release.

@charris: hmm, TBH I'm not sure what you mean by swapping and what are the newer interfaces here.

I'm talking about the inline functions that replaced macros in order to hide ndarray internals. I'm not sure that is what this is about, but I recall data pointers being swapped somewhere in f2py and that kept us from an easy path to using

#define NPY_NO_DEPRECATED_API NPY_API_VERSION

Now that I think about it, it would be good to have a release note for this, maybe under improvements.

Ok, added release note and Sturla's suggestion in #16524

Sorry, just curious... Is this approach fully safe with restoring always the same state? I noticed there is a longjmp in there. And we still have some annoying issues in the fft code with longjmp not being restored.

It seems to me however, that we may have to make it a doubly-linked list to really always correctly restore things if multiple threads finish in random order? But maybe I just need to think about it longer...

Ah, nvm. totally different situation since its on the stack here.