Last week, people interested in the matter met to talk about implementing DOM APIs in Rust. Here are my notes.
The summary of the meeting is that we shouldn't be designing bridge framework type of stuff ahead of time and for the time being we should instead address issues as they arise. We shouldn't expect to be able to use Servo's implementations of DOM APIs in a drop-in a manner in Gecko. Because Servo allocates Rust objects on the JavaScript heap, but Gecko doesn't allocate C++ objects on the JavaScript heap, the memory management arrangements of the two engines are fundamentally different and, therefore, the same WebIDL bindings won't work. Additionally, it was discussed whether there should be Gecko-specific WebIDL bindings. The conclusion was that there shouldn't be, at least for now. Instead, when implementing a WebIDL-specified API in Gecko in Rust, the existing bindings for C++ should be used and then the C++ code should call into Rust. If it happens that the implementation of an API could be shared between Servo and Gecko if it weren't for the binding incompatibility, the implementation of the API should be abstracted away from the binding so that both Servo-style and Gecko-style binding code can call into the shared implementation. As an exception to the general sentiment of not providing WebIDL bindings for Rust in Gecko, there was agreement that we should introduce the WebIDL annotation for requesting a USVString to be exposed as a guaranteed-valid UTF-8 subclass of nsACString instead of the usual UTF-16. The idea is that it should be easy to pass this onwards to Rust and view the data as &str in Rust. Additionally, there was some discussion about reference counting. Implementing an XPCOM binding for Rust was not a popular idea and was discarded. Still, it was considered important to be able to use Gecko-style reference counting in a cycle collector-compatible manner across the C++/Rust boundary. Specifically, we should introduce a macro for implementing AddRef, Release and associated cycle collection methods in Rust in a cycle collector-compatible way and we should implement a Gecko-flavored replacement for Rc<> that calls Gecko-style AddRef/Release as appropriate. Now that I'm looking at the hand-written notes that I made in the meeting, I notice that the above paragraph fails to say how the AddRef, Release and associated cycle collection-related calls are routed from C++ to Rust or from Rust to C++. There was some talk about vtable hacks, but my recollection is that those got rejected along with XPCOM. So as far as I can tell, we are left with the meeting not concluding how exactly these calls across the language boundary. (A remark of mine that was not discussed in the meeting and that I'm just adding onto the notes now as hopefully relevant to the last paragraph: If we don't want to hack vtables to make direct virtual calls between C++ and Rust, one way to use C linkage and FFI but still have the C++-side calls syntactically look like C++ method invocations that fit into existing C++-side smart pointers (etc.) is to interpret pointers returned from Rust as pointers to instances of a C++ class whose methods do nothing but call FFI functions with "this" as the first argument as seen in https://github.com/hsivonen/encoding-rs/blob/master/include/encoding_rs_cpp.h .) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
