Ian Henriksen

Probably related: https://github.com/ut-parla/Parla.py/issues/12

@sestephens73 mentioned on slack that this showed up in the matmul demo as well. The backtrace there was ``` 0x7fa9598e2188: (handler+0x28) 0x7fa95c966400: (killpg+0x40) 0x7fa95bf7837f: (get_nprocs+0x11f) 0x7fa95bf02aab: (arena_get2.part.4+0x19b) ``` I don't...

Here's an alternate theory as to what could cause this: the current VEC is a thread-local. Spawned threads don't automatically inherit the values of the thread-local variables of the thread...

@dialecticDolt please feel free to add more info here. Where do we have example code to reproduce this?

Actually they're VECs, but VEX might be a better acronym...

Either way, 100% agree with this.

Worth noting: if my theory about the context library not overriding glibc symbols in https://github.com/ut-parla/Parla.py/issues/68 is correct that bug will hold this up. Fortunately it's fixable.

Proposed fix: stop patching forwarding modules in as attributes on existing modules, and stop swapping stuff into and out of sys.modules when a new module import is detected. Here's a...

Okay, this seems like it might have performance penalties, but as a strawman suggestion... what if we capture non-function global objects into `__closure__` as well?

Yah, I'm not sure what to do about modifying bytecode. It'd be nice if we could avoid that. Thanks for pointing out that the opcodes are different. I'm also still...