Repository navigation
Binder requests from pythonx-concurrent (tracking) #164
Description
pythonx-concurrent SPEC §12 lists what it needs from the binder. Its implementation is deferred by the maintainer (2026-10-04), so this is a tracking list; each item becomes its own issue when its turn comes. Spec: https://github.com/thisisthepy/pythonx-concurrent/blob/develop/docs/SPEC.md (section 12).
- 1. Parent Job and dispatcher for exposed suspend calls (a caller-supplied CoroutineContext, without adding kotlinx.coroutines to the binder's dependencies).
- 2. A suspend wrapper over a Python awaitable (await() in Kotlin), submit from any thread, cancellation to Task.cancel().
- 3. Flow / StateFlow collectable from Python (generic declarations are not exposed today, SPEC U-4).
- 4. Opaque Kotlin objects as arguments (CoroutineDispatcher, Job).
- 5. A Python callable as a Kotlin function or Runnable, invokable from any Kotlin thread.
- 6. Exception mapping: CancellationException <-> CancelledError, Kotlin throwable kept as cause.
- 7. suspend function types in exposed signatures.
- 8. Free-threaded prebuilts for Android and iOS: Investigate: free-threaded CPython builds for Android and iOS built by us #163.
- 9. GIL release after initialisation: Binder: release the GIL after initialisation (SPEC C-4) #162.
- 10. Naming the loop a suspend result goes to when the calling thread has no running loop.
- 11. A supported way to resume a continuation from a Kotlin/Native thread on iOS (ROADMAP 13.3).
- 13. Stepping a Python coroutine from Kotlin as one call that takes and releases the GIL (coro.send/throw inside a given Context).
- 14. withGIL on a JVM virtual thread: Binder: withGIL on a JVM virtual thread can release the GIL from another carrier #161.
(12, wasm threads, is out of scope.)
Activity
b-re-w commentedon Oct 25, 2026
Binder status for the S7.8 request (Kotlin-mode Python on virtual threads): #161 is being fixed with option A. On desktop, the outermost withGIL on a JVM virtual thread raises IllegalStateException, so the carrier-thread mismatch cannot corrupt the interpreter. Run Python on platform threads. Option B (pin the virtual thread under a native frame) needs a public API change (withGIL's block becomes crossinline) and waits for a user decision. Until then S7.8 to S7.12 cannot run Python on virtual threads.
b-re-w commentedon Oct 25, 2026
Update for S7.8 to S7.12 (Kotlin-mode Python on virtual threads): #161 option B landed in develop (#337). On desktop, Python can now be entered from a JVM virtual thread. The outermost withGIL pins it to its carrier from PyGILState_Ensure to Release, so parking inside the scope is safe. API change: withGIL { } and Python3.withPython { } take a crossinline block, so a non-local 'return' from inside them no longer compiles. Note: a pinned virtual thread holds its carrier while it waits inside the scope. Not yet verified inside a GraalVM native image.