Questions regarding thread safety and free threading compatibility

[neutrinoceros]

I think supporting free-threading here is necessary to enable further testing in astropy. I don't think the task is particularly difficult, from afar, but there are a couple broad questions I'd like to ask @avalentino and @mhvk first:

1. is there any form of mutable global state somewhere, like a counter, a registry, or a cache of some sort ?
2. I am aware at least some erfa functions support an out argument, which immediately make them impure functions, but that's very common in numpy itself so it should suffice to adopt whatever relevant pattern or policy from upstream. My question is: are there any other ways in which erfa functions might be impure ?

if the answers to both questions is no, then I expect the work to be quite trivial.

[ColmTalbot]

FWIW, I looked into this briefly last month and the most problematic thing I could see is that there is an array of leap seconds that is stored globally in erfa.
There's a comment about this not necessarily being a permanent change, and I think the rate of adding new leap seconds has slowed, but I was able to get the freethreaded tests to pass by making this thread local.

I'm happy to open a PR with my changes and also to help out more broadly with enabling free threading compatibility.

[neutrinoceros]

I'd happily review your PR. Thanks !

[ColmTalbot]

Great! I'll open it ASAP, although I noticed liberfa/erfa#103 this morning, which I had missed, but any changes should probably be coordinated with.

[mhvk]

I think that indeed the only global state is the leap-second table.

On side effects (i.e., impure functions), there are some cases in the SOFA/ERFA code where an astrom structure is passed in, and internally some of the structure's elements are adjusted. In the wrappers, these are "inout" arrays. But conceptually, this is no different from setting out to one of the input arrays in numpy ufuncs.

[ColmTalbot]

On side effects (i.e., impure functions), there are some cases in the SOFA/ERFA code where an astrom structure is passed in, and internally some of the structure's elements are adjusted. In the wrappers, these are "inout" arrays. But conceptually, this is no different from setting out to one of the input arrays in numpy ufuncs.

From what I can tell, numpy doesn't provide any guarantees about thread safety if an output array is passed, so I wasn't planning on trying to handle that.

[mhvk]

From what I can tell, numpy doesn't provide any guarantees about thread safety if an output array is passed, so I wasn't planning on trying to handle that.

My point was that some of the erfa wrappers around the ufuncs call the ufunc with an out argument, since the C code does adjust the structures partially. For instance, https://pyerfa.readthedocs.io/en/latest/api/erfa.aper.html.

[avalentino]

I think that the question has been answered and now we have two PW (#108 and #215, thanks to @ColmTalbot ).
Can we close this issue?

[neutrinoceros]

yes. Thanks for reminding me !