| future_tester.rs |
Test basic interop between Rust futures and JS async code
[FutureTester::make_future] returns a future and the other methods manipulate it manually. |
1638 |
| lib.rs |
|
395 |
| oneshot.rs |
Simple oneshot channel implementation.
In practice, we would probably use the `oneshot` crate for this, but it's not worth bringing in
that dependency for this test fixture. |
1817 |
| roundtrip.rs |
Some barely async functions that round-trip data.
The purpose of these is to test the lift/lower implementations in the async code. |
1695 |
| wrapped_sync_call.rs |
Test wrapping sync Rust calls and making them async.
This is intended to mimic what we do in application-services: create a synchrounous API, then
wrap it so that most methods are async and run in a worker queue.
This provides the essentially same functionality as the automatic async wrapping that is
available by editing `config.toml` so why do it?
- Implementing the async wrapping in Rust leads to better docs. The auto-generated API
reference will show which functions are sync and which are async. Telling users that
sync functions are actually actually async because of UniFFI magic would lead to confusion.
- It opens the door to future performance improvements. Some methods could be async without
this wrapper and without sending anything to a background thread. Fxa API calls using an
async HTTP client would be one example. Some methods could be split into a "real" async part
and a wrapped async part.
- Async Rust code allows for new patterns. Maybe the FxA state machine would be better
modelled as an async actor rather than a bunch of sync methods protected by a Mutex. |
5094 |