Skip to content

fix: guard asyncify_stop_unwind() for async web API import unwinds (i…#25

Open
itsbryanman wants to merge 1 commit into
6over3:mainfrom
itsbryanman:fix/async-web-apis-issue-7
Open

fix: guard asyncify_stop_unwind() for async web API import unwinds (i…#25
itsbryanman wants to merge 1 commit into
6over3:mainfrom
itsbryanman:fix/async-web-apis-issue-7

Conversation

@itsbryanman

Copy link
Copy Markdown

Fix: guard asyncify_stop_unwind() for async web API import unwinds (issue #7)

Root Cause

The runtime loop in stubs/runtime.c unconditionally called asyncify_stop_unwind() after every return from main(). When an asyncify import (call_host_function) triggered an unwind, this cleared __asyncify_state from 1 (UNWINDING) to 0 before the export returned to JS. The asyncify-wasm host then saw state 0, concluded execution finished normally, and never awaited the pending Promise — the async call was silently dropped.

The Fix

pl_asyncify_unwind_buf is set by zeroperl's own asyncify_start_unwind() macro for C-level unwinds (setjmp/longjmp/scan), but NOT by the asyncify transform's internal import handling. This makes it a clean discriminator:

  • pl_asyncify_unwind_buf != NULL → C-level unwind → safe to call asyncify_stop_unwind() and dispatch
  • pl_asyncify_unwind_buf == NULL → normal exit OR async import unwind → do NOT clear __asyncify_state, let asyncify-wasm handle it

Only stubs/runtime.c needed to change. No new files, no changes to machine.c, machine.h, or zeroperl.c.

Fixes #7

/claim

…ssue 6over3#7)

Only call asyncify_stop_unwind() when pl_asyncify_unwind_buf is non-NULL,
which indicates a C-level (setjmp/longjmp/scan) unwind. When an asyncify
import like call_host_function triggers an unwind, the transform bypasses
our macro so pl_asyncify_unwind_buf stays NULL. Calling asyncify_stop_unwind()
in that case clears __asyncify_state from 1 (UNWINDING) to 0 before the
export returns to JS, hiding the pending async op from asyncify-wasm.

Fixes 6over3#7
@itsbryanman itsbryanman force-pushed the fix/async-web-apis-issue-7 branch from 5182442 to b5d6582 Compare May 18, 2026 11:01
@itsbryanman

Copy link
Copy Markdown
Author

/claim #7

@itsbryanman

Copy link
Copy Markdown
Author

Hey, just checking in on this one. The branch is still up to date with main and the fix is ready for review. Happy to add tests or a CHANGELOG entry if that would help move this forward. Let me know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Asynchronous Web APIs

1 participant