Newly spawned threads should inherit the interpretation context

[jfeser]

We use contextvar.ContextVar to store the current interpretation context. These variables are thread-local and their value is not inherited by new threads (python/cpython#128555). This causes some surprising behavior when using APIs that call operations from within spawned threads internally.

from concurrent.futures import ThreadPoolExecutor

from effectful.ops.semantics import handler
from effectful.ops.types import Operation


@Operation.define
def x():
    return 0


with handler({x: lambda: 1}):
    assert x() == 1
    with ThreadPoolExecutor(max_workers=1) as executor:
        assert executor.submit(x).result() == 1

There's active upstream discussion about this issue:

• gh-154562: Add ContextVar(thread_inheritable=...). python/cpython#154564
• Allow libraries to opt-in to context variable inheritance by new threads python/cpython#154562

[eb8680]

IIUC asyncio.to_thread works around this by manually calling contextvars.copy_context:

async def to_thread(func, /, *args, **kwargs):
    loop = events.get_running_loop()
    ctx = contextvars.copy_context()
    func_call = functools.partial(ctx.run, func, *args, **kwargs)
    return await loop.run_in_executor(None, func_call)

[jfeser]

Yes, if you have control over thread spawn, then you can work around. The issue we ran into resulted from a library that we had given effects to call spawning its own threads internally.

[jfeser]

I think this may be unsolvable on the library level until things change upstream.