mirror of
https://github.com/mozilla/gecko-dev.git
synced 2025-11-06 19:29:24 +02:00
79c4dcd5b0
Started callback interface functionality to UniFFI. Currently this only
supports the async fire-and-forget use case, where Rust queues a JS
function to run, but doesn't wait (or `await`) for the response.
The basic system is:
- The JS code registers a callback interface handler with the C++
code. This handler is responsible for the specifics of invoking the
callback.
- The C++ code defines a function to call a JS handler. Once the JS
handler registers itself with C++, the C++ registers it's function
with Rust.
- The C++ code queues the call to the JS main thread.
- Because of how UniFFI handles callback interfaces, the C++ code can
be "dumb". UniFFI sends a object id, method id, and RustBuffer
encoding all arguments. This means C++ doesn't need to care about
the specific arguments, they get unpacked by JS.
I tried to keep the generated code as simple as possible by moving the
complexity to static code. For JS this meant writing a generic
`UniFFICallbackHandler` class in the static code that the generated code
constructs. For C++ this meant the generated code defines a
`UniFFIGetCallbackInterfaceInfo` function that returns a struct with all
the data specific to a callback interface (it's name, the UniFFI
scaffolding init function, etc). The static code can then define a
generic `QueueCallback` function that looks up the callback interface
info using the interface ID and then makes the call.
Allow UniFFI functions to run on the main thread rather than always
being dispatched to a worker thread. This allows us to test invoking
callback interfaces from the main thread thread. I don't think we will
use this much currently, since we don't want to block the main thread
for any significant amount of time. However, this will pair well with
the next step in the project which is async -- allowing async Rust
functions to call async JS functions. In that scenario, dispatching to
the worker thread is unnecessary.
Callback interface objects present a potential memory leak, since you
can easily create a cycle between a JS Callback object and a UniFFIed
Rust object, and the GC has no way of detecting it. To try to detect
these there's some shutdown code that checks that there are no callbacks
registered during shutdown and prevents any future callbacks from being
registered.
Added a `config.toml` file and code to parse it. This is needed to
specify which functions should run on the main thread.
Updated the git commits for the several UniFFI examples/fixtures.
Differential Revision: https://phabricator.services.mozilla.com/D156116
75 lines
2.4 KiB
C++
75 lines
2.4 KiB
C++
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
/* vim:set ts=2 sw=2 sts=2 et cindent: */
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
#ifndef mozilla_UniFFICallbacks_h
|
|
#define mozilla_UniFFICallbacks_h
|
|
|
|
#include "mozilla/StaticPtr.h"
|
|
#include "mozilla/dom/UniFFIRust.h"
|
|
#include "mozilla/dom/UniFFIScaffolding.h"
|
|
|
|
namespace mozilla::uniffi {
|
|
|
|
/**
|
|
* UniFFI-generated scaffolding function to initialize a callback interface
|
|
*
|
|
* The Rust code expests us to pass it a ForeignCallback entrypoint for each
|
|
* callback interface.
|
|
*/
|
|
typedef void (*CallbackInitFunc)(ForeignCallback, RustCallStatus*);
|
|
|
|
/**
|
|
* All the information needed to handle a callback interface.
|
|
*
|
|
* The generated code includes a function that maps interface ids to one of
|
|
* these structs
|
|
*/
|
|
struct CallbackInterfaceInfo {
|
|
// Human-friendly name
|
|
const char* mName;
|
|
// JS handler
|
|
StaticRefPtr<dom::UniFFICallbackHandler>* mHandler;
|
|
// Handler function, defined in the generated C++ code
|
|
ForeignCallback mForeignCallback;
|
|
// Init function, defined in the generated Rust scaffolding. mForeignCallback
|
|
// should be passed to this.
|
|
CallbackInitFunc mInitForeignCallback;
|
|
};
|
|
|
|
Maybe<CallbackInterfaceInfo> UniFFIGetCallbackInterfaceInfo(
|
|
uint64_t aInterfaceId);
|
|
|
|
#ifdef MOZ_UNIFFI_FIXTURES
|
|
Maybe<CallbackInterfaceInfo> UniFFIFixturesGetCallbackInterfaceInfo(
|
|
uint64_t aInterfaceId);
|
|
#endif
|
|
|
|
/**
|
|
* Register the JS handler for a callback interface
|
|
*/
|
|
void RegisterCallbackHandler(uint64_t aInterfaceId,
|
|
dom::UniFFICallbackHandler& aCallbackHandler,
|
|
ErrorResult& aError);
|
|
|
|
/**
|
|
* Deregister the JS handler for a callback interface
|
|
*/
|
|
void DeregisterCallbackHandler(uint64_t aInterfaceId, ErrorResult& aError);
|
|
|
|
/**
|
|
* Queue a UniFFI callback interface function to run at some point
|
|
*
|
|
* This function is for fire-and-forget callbacks where the caller doesn't care
|
|
* about the return value and doesn't want to wait for the call to finish. A
|
|
* good use case for this is logging.
|
|
*/
|
|
MOZ_CAN_RUN_SCRIPT
|
|
void QueueCallback(size_t aInterfaceId, uint64_t aHandle, uint32_t aMethod,
|
|
RustBuffer aArgs);
|
|
|
|
} // namespace mozilla::uniffi
|
|
|
|
#endif // mozilla_UniFFICallbacks_h
|