Wie kann man Node.js-Add-On-Bindungen in C ++ in die Zielkompilierung in WASM konvertieren? ⇐ C++

[Anonymous]

Kontext
Es gibt eine vorhandene HTTP/3- und Webtransport-Bibliothek, die exklusiv für node.js unter Verwendung von Node-API geschrieben wurde. Die Server -Implementierung funktioniert mit Chromium und Firefox als Clients. Node führt den Server gut aus. Bun kann den Server jedoch mit einem Fehler
ausführen

Code: Select all

E0413 22:42:56.932056   82865 quic_connection.cc:2613] quic_bug_12714_21: ProcessUdpPacket must not be called while processing a packet.
terminate called after throwing an instance of 'Napi::Error'
what():  ReadableStream is not readable
Aborted
< /code>
deno

startet den Server, dann Fehler, wenn der Client versucht,
zu verbinden

Code: Select all

terminate called after throwing an instance of 'Napi::Error'
what():  this.socketInt.getSendQueueCount is not a function
Aborted

< /code>
Deno's HTTP/3 WebTransport

Implementierung funktioniert für Deno und Chrome als Clients funktioniert nicht, wenn Firefox der Client ist. Um die Knoten-API-Bindungen in C ++ in WASM (mit oder ohne WASI-Unterstützung) umzuwandeln, um denselben Servercode mit Knoten , demo , bun auszuführen, und schließlich in Chrome .

Code: Select all

    void Http3WTSessionJS::processStream(bool incom, bool bidi, uint64_t sendOrder, uint64_t sendGroupId, Http3WTStream *stream)
{
Napi::HandleScope scope(Env());
Http3Constructors *constr = Env().GetInstanceData();
Napi::Object strobj = constr->stream.New({});
Http3WTStreamJS *strjs = Napi::ObjectWrap::Unwrap(strobj);
strjs->setObj(stream);
if (!stream->gone())
strjs->Ref();

stream->setJS(strjs);

Napi::Object objVal = Value().Get("jsobj").As();

Napi::Object retObj = Napi::Object::New(Env());
retObj.Set("stream", strobj);
retObj.Set("incoming", incom);
retObj.Set("bidirectional", bidi);
retObj.Set("sendOrder", sendOrder);
retObj.Set("sendGroupId", sendGroupId);

objVal.Get("onStream").As().Call(objVal, {retObj});
}
< /code>
and there's a bunch of them

Here are some pointers for http/3: https://github.com/fails-components/webtransport/blob/master/transports/http3-quiche/src/http3wtsessionvisitor.cc
...
all these use NAPI for node binding and would need a replacement, if compiled to wasm. (Including the mechanims for alarams and napialarmfactory and sockerjswriter.cc.

There's a tsconfig.json

und eine vorhandene Build-Roadmap, die CMake-js verwendet, die Zeilen wie
enthält

Code: Select all

switch (argv[2]) {
case 'prebuild':
try {
await prebuild([
'-t',
'6',
'-r',
'napi',
'--strip',
...pbargspre,
'--backend',
'cmake-js',
'--',
...pbargs
])
} catch (error) {
console.log('prebuild failed')
process.exit(1)
}
break
case 'install':
try {
const pbres = await prebuildInstall([
'-r',
'napi',
'-d',
'-t',
'6',
'--verbose'
])

Status, Optionen
Wenn niemand diesen Fall auf diesen Fall gestoßen und ihre Schritte dokumentiert hat, dann ist die Standardantwort die erforderlichen Konvertierungen zur Vorbereitung für die Kompilierung zu WASM und schließlich Javascript, wobei Binarys WASM2JS , BY Hand. Auf diese Art von Code begegnet und verwendet ein automatisiertes vorhandenes Build-System, das NAPI -Bindungen umgewandelt hat, um Funktionen zu exportieren, die ein Tool wie WASI-SDK-Clang oder sogar Emscripten; Wenn ja, was ist Ihre Roadmap?