Switch to generic language handler interface #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Need to wire them up to something now...
Qard
force-pushed
the
add-generic-lang-handler-interface
branch
7 times, most recently
from
11393d8 to
7bbd342
Compare
Qard
force-pushed
the
add-generic-lang-handler-interface
branch
from
7bbd342 to
6c844f9
Compare
Qard
force-pushed
the
add-generic-lang-handler-interface
branch
from
12f2dee to
ff04c06
Compare
Qard
force-pushed
the
add-generic-lang-handler-interface
branch
11 times, most recently
from
ad7f8e9 to
7729bd5
Compare
Qard
force-pushed
the
add-generic-lang-handler-interface
branch
21 times, most recently
from
8f04561 to
a0c467b
Compare
Qard
force-pushed
the
add-generic-lang-handler-interface
branch
from
a0c467b to
e7cf385
Compare
Merged
Qard
force-pushed
the
main
branch
4 times, most recently
from
3f7ed68 to
c667963
Compare
Qard
added a commit
that referenced
this pull request
Dec 15, 2025
The root cause of the CI crashes was that Arc<Sapi> could be dropped (and tsrm_shutdown() called) while a blocking task was still executing PHP code. This happened because: 1. Embed holds Arc<Sapi> to keep PHP SAPI alive 2. spawn_blocking() creates a task that uses PHP functions 3. If Embed is dropped before the blocking task completes, Sapi refcount goes to 0, triggering Sapi::drop() which calls tsrm_shutdown() 4. The still-running blocking task tries to call estrdup(), but TSRM storage is already freed, causing EXC_BAD_ACCESS at address 0x0 The fix clones Arc<Sapi> into the blocking task closure, ensuring the Sapi stays alive for the entire duration of PHP operations. Stack trace that led to this fix: thread #24, name = 'tokio-runtime-worker', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: libphp.dylib`_emalloc + 44 frame #1: libphp.dylib`_estrdup + 40 frame #2: binding.node`BlockingTask<T>::poll + 144 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Still lots more to be done, but with this there's now an interface to transport all the data of http request and response into and out of the other VM. It's also done generically, so could be easily reused for other languages in the future, we'd just need to implement the Handler trait to make use of those data types for the transition between Node.js req/res types and whichever languages own request and response data types or interfaces.
With this I'm able to inject the various header-related superglobals into PHP, execute code, and receive headers and status code written out to the response, transporting all of them back to Node.js. The next major bit of work is getting the input and output stream working. The POST body forwarding looks to be straightforward. I'm not yet sure why I'm not getting output to
ub_writethough. 🤔