source-academy / py-slang / 30200213350

86%

push

github

py2js: closure_call_sync fast path for module closures called from Python (#353)

* py2js: give module closures crossing into Python a closure_call_sync fast path

moduleToPython's DataType.CLOSURE case (a module function imported into
Python, e.g. `from math import sqrt`) always built an asyncOnly PyFunction:
a defensive-backstop sync body that unconditionally threw, and an async
body that unconditionally paid the mandatory async-generator tax via
closure_call_unchecked - even for a closure that carries a `.sync` twin
proving it never needs a real host round-trip.

That fast path already exists and is already generic: GenericDataHandler.
closure_call_sync looks up a closure's underlying function in closureMap
and calls its `.sync` twin directly if present, regardless of whether the
closure originated from a module or from Python - it's the same mechanism
pythonToModule's `.sync` attach already uses for the opposite direction
(a Python closure crossing into a module, e.g. sound's wave sampling).
Only the moduleToPython side never attempted it.

The sync body now tries dh.closure_call_sync first (converting arguments/
result through the same restricted scalar converters, moduleToPythonSync/
pythonToModuleSync, the other direction's fast path already uses), and
falls back to the exact same "needs a frontend round-trip" error only when
no `.sync` twin is available for that specific call - a dynamic, per-call
decision now, rather than the fixed asyncOnly flag that used to reject
every sync call unconditionally regardless of what the closure was capable
of. The asyncBody fallback is unchanged.

Motivated by the modules repo's pix_n_flix migration: a redesigned pixel
API (get_pixel_value/set_pixel_value over an opaque image handle) needs to
be called from inside a student's filter up to width*height*8 times per
frame - the same shape of hot loop as sound's per-sample wave callback,
just the reverse direction across the module boundary. Depends on
source-aca... (continued)

4409 of 5511 branches covered (80.0%)

Branch coverage included in aggregate %.

15 of 17 new or added lines in 1 file covered. (88.24%)

9563 of 10710 relevant lines covered (89.29%)

178044.66 hits per line