ThreadPool: access violation after many short submit().join() (DECREF Python objects off the GIL) #1

Problem

Calling pool.submit(...).join() in a tight loop eventually crashes with a native access violation (often shows up later in marshal / join, so it looks unrelated).

Dedicated cthreads.thread(...).join() does not hit this.

Reproes with a trivial kernel (no Shared, no TBuffer):

@Thread
def add(a: int, b: int) -> int:
    return a + b

pool = ThreadPool(2).start()
for i in range(5000):
    j = pool.submit(add, i, 1)
    j.join()
    assert j.result() == i + 1
pool.stop()

Cause

Pool workers are bare OS threads. Each task keeps pybind handles (params_keep, SpawnedKernel / py::objects) in a std::function. When that task is destroyed on the worker, those handles DECREF without holding the GIL → undefined behavior / delayed AV.

This is separate from the SharedHost pin fix (fast Shared jobs freeing native slots while later submits still register).

Fix

After a pool job finishes (and when a queued job is dropped on stop()), clear the task’s Python-owning state under py::gil_scoped_acquire. Drain the dropped queue outside the queue mutex so GIL acquire can’t deadlock with that lock.