Skip to content

Attempt to handle async web API unwinds#20

Open
Robert0303-C wants to merge 1 commit into
6over3:mainfrom
Robert0303-C:async-web-apis
Open

Attempt to handle async web API unwinds#20
Robert0303-C wants to merge 1 commit into
6over3:mainfrom
Robert0303-C:async-web-apis

Conversation

@Robert0303-C

Copy link
Copy Markdown

This is an attempt to address issue #7 - Asynchronous Web APIs.

The Problem

zeroperl uses asyncify for setjmp/longjmp (from ruby/wasm), and there's a conflict when trying to use asyncify for async web APIs via the --asyncify --pass-arg=asyncify-imports@... build flags.

The core issue is that both asyncify uses share the same state machine, which can cause:

  1. Runtime traps when trying to rewind back to C code
  2. Infinite loops when code makes it back to __wrap_read

This Attempt

This change attempts to isolate async web API unwinds from setjmp unwinds by:

  1. Adding a global state to track async web API unwinds
  2. Handling them separately in the runtime loop
  3. Providing a callback (asyncjmp_handle_async_web_rewind) for when async operations complete

Limitations

However, the fundamental issue is that both asyncify transformations share the same asyncify state machine. The re-entrancy issues mentioned in asyncify releases (https://github.com/GoogleChromeLabs/asyncify/releases) suggest this is a known problem.

A proper fix likely requires:

  1. Changes to how asyncify state is managed when both are active
  2. Or using a different mechanism for either setjmp or async web APIs
  3. Or fixes to the asyncify runtime itself

The issue was originally closed as "completed" with a note that "This has been identified as a bug in asyncify runtime and the bounty is now reserved for it's maintainer."

Testing

This change compiles but has not been extensively tested due to the complexity of the asyncify interaction.

@Robert0303-C

Copy link
Copy Markdown
Author

/claim

The issue is that both setjmp/longjmp and async web APIs use the same
asyncify mechanism (pl_asyncify_unwind_buf), causing re-entrancy
conflicts when an async web API call happens during a setjmp context.

Solution: Add a separate unwind buffer for async web API operations
that is isolated from the setjmp unwind state:

1. machine.h/c: Add async_web_api_unwind(), async_web_api_stop(),
   async_web_api_handle_unwind() with separate _async_web_api_buf

2. runtime.c: Check async_web_api_handle_unwind() in the asyncify
   handling loop to properly handle async web API rewind

This allows setjmp and async web APIs to coexist without conflicts.

Fixes 6over3#7
@Robert0303-C

Copy link
Copy Markdown
Author

/claim

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.

1 participant