Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply theskip news label instead.

Requesting a look from@ZeroIntensity.

Made requested changes, also made arrayiter safe.

Also found a good old-fashioned non-free-threaded bug which probably goes back a long way - if try toarrayiter.__setstate__() when it is exhausted then segfault, fixed here obviously.

Question remaining about need to lock bytes source object infrombytes() or if holding the buffer is sufficient?

Also found a good old-fashioned non-free-threaded bug which probably goes back a long way - if try toarrayiter.__setstate__() when it is exhausted then segfault, fixed here obviously.

Could you separate that out from this PR and submit a dedicated PR for this bug? We might want to backport it.

Regarding the style nits: please make sure all new code (and inmost cases, also changed code) followPEP-7.

Still would like to know ifarray_array_frombytes() really needs to lock thebytes object or if just holding the buffer is sufficient. The idea being trying to prevent the CONTENTS of the buffer changing during the operation. Just holding buffer is not enough if is writable but not sure locking object would help that anyway.

❯./python -mtest test_array -R 3:3Using random seed: 19191006670:00:00 load avg: 36.22 Run 1 test sequentially in a single process0:00:00 load avg: 36.22 [1/1] test_arraybeginning 6 repetitions. Showing number of leaks (. for 0 or less, X for 10 or more)123:456XX. ...0:00:16 load avg: 28.56 [1/1] test_array passed== Tests result: SUCCESS ==1 test OK.Total duration: 16.1 secTotal tests: run=886 skipped=1Total test files: run=1/1Result: SUCCESS

No refleaks.

No refleaks.

Thx for the onboarding with this@ZeroIntensity

The PR regressed free threading performance substantially on the scimark benchmarks from pyperformance, so I'm going to revert the PR for now. We'll need to figure out a way of makingarraymodule.c thread-safe without regressing perf.

The PR regressed free threading performance substantially on the scimark benchmarks from pyperformance, so I'm going to revert the PR for now. We'll need to figure out a way of makingarraymodule.c thread-safe without regressing perf.

Will play with it checking perf along the way to see if a lesser standard of thread-safe can work (ignore data integrity and just make sure nothing crashes).

I looked at it briefly under Linux'sperf record and noticed a few things:

• The most important functions arearray_subscr,array_item, andarray_ass_subscr in that order. Probably nothing else matters much.
• The critical section code is less efficient because it's in a shared library so there's a bunch of non-inlined calls to_PyThreadState_GetCurrent().

We can consider using a similar strategy asPyListObject where we avoid locking during most read-only single-element accesses. It definitely will complicate the implementation, though.

We can also consider movingarraymodule.c out of a shared library. I'm not really sure what the considerations are for that.

We can consider using a similar strategy asPyListObject where we avoid locking during most read-only single-element accesses. It definitely will complicate the implementation, though.

List deals with objects with their ownPyObject headers, array is just a blob of memory so not sure how much of that strategy translates.

I guess it'll be a bit simpler thanPyListObject then. The primary thread-safety hazard is attempting to read or write an entry inob_item while thearrayobject is concurrently resized andob_item is freed and re-allocated.

So if we adapt the list strategy it might look like:

• Lock thearrayobject during resize and multi-element accesses (e.g.,array_subscr with slices)
• Mark thearrayobject as shared if it's accessed by a non-owning thread (requires locking)
• When resizing thearrayobject, use QSBR to delay the free ofob_item if thearrayobject is shared
• Single-elementarray_subscr andarray_ass_subscr can generally avoid locking

I guess it'll be a bit simpler thanPyListObject then. The primary thread-safety hazard is attempting to read or write an entry inob_item while thearrayobject is concurrently resized andob_item is freed and re-allocated.

Simplest worst case scenario thing depending on performance could be a spinlock to make access toob_item andob_size shared atomic. Might lose integrity but keep speed and avoid crashes, put responsibility for the data validity on user in multithreaded scenarios.

In any case, got some crude numbers for impact of justarray_item,array_subscr andass_subscr by removing their locks to see rough best case scenario. For reference the order is: OLD array freethread main, NEW slow array freethread, NOLOCK slow array freethread without locking onarray_item,array_subscr orarray_ass_subscr:

### scimark_fft ###OLD:    Mean +- std dev: 238 ms +- 8 msNEW:    Mean +- std dev: 282 ms +- 11 msNOLOCK: Mean +- std dev: 247 ms +- 4 ms### scimark_lu ###OLD:    Mean +- std dev: 88.7 ms +- 3.9 msNEW:    Mean +- std dev: 95.0 ms +- 1.5 msNOLOCK: Mean +- std dev: 88.5 ms +- 1.8 ms### scimark_monte_carlo ###OLD:    Mean +- std dev: 53.4 ms +- 0.5 msNEW:    Mean +- std dev: 56.0 ms +- 0.5 msNOLOCK: Mean +- std dev: 53.9 ms +- 0.9 ms### scimark_sor ###OLD:    Mean +- std dev: 98.1 ms +- 1.7 msNEW:    Mean +- std dev: 100  ms +- 1 msNOLOCK: Mean +- std dev: 97.7 ms +- 1.3 ms### scimark_sparse_mat_mult ###OLD:    Mean +- std dev: 3.84 ms +- 0.14 msNEW:    Mean +- std dev: 4.71 ms +- 0.07 msNOLOCK: Mean +- std dev: 3.87 ms +- 0.13 ms

I have all weekend to play with this so will try various things and what you mentioned.

Continued in#130771.