Prevent taking the GIL in ForAll - #4581

cc @seibert @sklam

The patch makes sense. Using @cfunc is certainly the quickest way to add a native function. I couldn't think of any reason to not use @cfunc. The alternative is to write it in C in one of the numba helper lib, which feels like way too much work.

We just need to run it through the our internal smoketest and we can accept it once it pass.

The patch makes sense. Using @cfunc is certainly the quickest way to add a native function. I couldn't think of any reason to not use @cfunc. The alternative is to write it in C in one of the numba helper lib, which feels like way too much work.

We just need to run it through the our internal smoketest and we can accept it once it pass.

@sklam great, let us know if we can help in any way. This is unfortunately a big blocker for us.

Assuming nothing blows up in CI, it will be merged to master by the end of the day

That's great to hear, thanks @sklam and @seibert !

Passed CI, so marking this for merge this evening.

Thanks @seibert !

The CUDA Occupancy API provides multiple versions of cuOccupancyMaxPotentialBlockSize, only one of which takes a function to calculate smem size. In this case Numba is passing a function that always returns zero. If Numba always does that, I would suggest instead changing Numba to only ever call a version of cuOccupancyMaxPotentialBlockSize that takes an integer amount of dynamic shared memory rather than a function pointer.

@harrism I just saw that the CUDA Occupancy API uses the runtime API, whereas Numba only uses the driver API (feel free to correct me if I'm wrong here), and that's probably why it uses cuOccupancyMaxPotentialBlockSize.

In the interest of unblocking ucx-py, we'll merge this PR, but investigate @harrism's suggestion.

@pentschev yep, I was referring to the driver API. The driver API has a version of cuOccupancyMaxPotentialBlockSize that takes an integer amount of dynamic shared memory rather than a function callback.