Ian Henriksen

Specifically worth noting: I think the libunwind trace printing has succeeded in finding symbols for some functions within a VEC. For example, the segfaults in https://github.com/ut-parla/Parla.py/issues/68 include what appear to...

I think the breaks in the traces usually correspond to places where a function in one VEC calls a function in another. Maybe the issue is jumping between tables?

Arguably we really only need to override `_frozen_importlib._gcd_import` instead of `__import__` and `importlib.import_module`. That's an internal interface so I'm not 100% sold on this, but it's not likely to change...

Another alternative that now seems like it might be viable: fix the upstream `PyImport_*` routines to fully respect overrides. I realized today that they are already inconsistent with the documentation....

Minor follow-up here: after thinking this one over for a while, I think the best approach is to try addressing this upstream in cpython. Letting someone override `__import__` but only...

Submitted upstream as https://bugs.python.org/issue43870. It seemed like a minor enough thing to just discuss on the issue tracker rather than their mailing list.

We can work around this for now by importing cupy like this: ``` import cupy_backends.cuda.libs.cublas, cupy_backends.cuda.libs.cusolver, cupy_backends.cuda.libs.cusparse, cupy ``` That lands me with some other esoteric error, but at least...

Worth noting: this bug is the root cause of a performance pathology in the case where we've imported many many modules. The key pathological loop is https://github.com/ut-parla/Parla.py/blob/d82e6d573a5cd5b1e492a99a0106cd90e632961e/parla/multiload.py#L373. That loop is...

Given the lack of response upstream probably a good plan of action would be to prepare a CPython patch for the C API functions that respects `__import__` overrides, see if...

IIRC, we need some cleanup beyond https://github.com/ut-parla/Parla.py/pull/58 to make sure things are properly import-order independent within parla modules.