[Enhancement] Release GIL

[miili]

Releasing the GIL during marching would open this library for threaded applications and provide a very significant speed up to many use cases.

I am aware of #67 #36 and propose a re-evaluation of releasing the GIL.

@jkfurtney concern that manipulating the input data during marching is reasonable, but can be mitigated effectively by flagging the input numpy arrays read-only during marching.

https://numpy.org/doc/stable/reference/c-api/array.html#c.PyArray_ENABLEFLAGS

The benefits of efficient multi-threading justify the costs.

[jkfurtney]

Here is a quick thought on this: all the calculation is done in C++ where we can multithread without releasing the GIL. We could make a new entry point on the Python side that can take several input arrays and process them simultaneously. This is a compromise that does not give full flexibility but is safer on the Python side. Would this suit your use case?

(With the limited time I have available I am going to focus on getting an update out that adds 3.12 compatibility and I want to work on the higher order narrowband initialization.)

[miili]

Hi Jason,

that proposition would change the API and is not a drop-in to the existing implementation.
Can I go ahead and pitch a PR for the write flag on the array?

Best,
M

[miili]

@jkfurtney if this is too hacky, we can (1) introduce a second method with the same signature which is releasing the GIL for the computation.

Or (2) introduce a keyword to release the GIL.

Both options are backwards compatible.

What do you think?