Ian Henriksen

Yah, we'll see if that was a fluke from me testing on a busy machine or if there's actually any difference. Even if it actually matters, I'm actually more okay...

Alright, after collecting more data, I'm seeing some slight performance improvement without the cache. It's not statistically significant though since there's a lot of noise in the data. I'll collect...

Clearing from the milestone since I don't expect upstream to move quickly on any of these issues. We'll just have to de-emphasize the hacks as central since we're still trying...

Also submitted https://bugs.python.org/issue43895 and https://github.com/python/cpython/pull/25487 upstream. No idea if it'll garner any comment there since it's a minor cleanup item from their perspective. Either way we have a workaround here,...

Shared object handles patch is accepted upstream, so that's one down.

Honestly, I'm not 100% sure of what the right fix for this is. Part of me is saying that it's okay to let people write a deadlock as long as...

> I think we might actually already track that. Or at least I thought about doing it. The reason was that I wanted to provide fake stacks for exceptions so...

Another thought on this: this would be *very* easy to detect in the sequential execution case. We need to add that execution mode for better debugging anyway. During sequential execution...

Here's my current best theory for what might be causing this: our overrides in libparla_context may not be getting correctly preloaded. The resulting shared object has libc as a dependency...

All that said, that theory doesn't necessarily mean that there couldn't also be something wrong with our thread affinity wrappers.