Crates.io | flarch |
lib.rs | flarch |
version | |
source | src |
created_at | 2022-07-05 18:26:17.700598+00 |
updated_at | 2025-02-25 07:12:07.711592+00 |
description | Common implementations for libc and wasm |
homepage | https://fledg.re |
repository | https://github.com/ineiti/fledger |
max_upload_size | |
id | 619946 |
Cargo.toml error: | TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
The Fledger Arch module holds common methods that are used by libc and wasm implementation. The following methods / structures are available:
DataStorage
allows to store key/value pairs in a file / localStoragetasks::*
various useful tools:
now() -> i64
- returns the current timestamp in milliseconds as i64spawn_local<F: Future<Output = ()> + 'static>(f: F)
- spawns a future locallywait_ms(ms: u32)
- async wait in millisecondsinterval(dur: Duration)
- creates a stream that will send the expected time of resolution every dur
Interval
- a stream created by interval
node
compiles for the node targetI wanted to create a common code for both the libc- and wasm-implementation for
Fledger.
Unfortunately it is difficult by the fact that libc allows to use threads
(and sometimes needs them), so some structures need to have the Send
and Sync
traits.
But these traits are not available for all necessary websys-modules!
So I came up with the idea of linking all modules using a Broker
system.
In short, all input and output for a module are defined as messages.
Then each module handles incoming messages and produces outgoing messages.
Modules can be linked together by defining Translators
that take messages
from one module and translate them into messages for the other module.
All message-passing is done asynchronously and doesn't need intervention by the programmer. However, this means that tests sometimes need to wait for all messages to be transmitted, before the results are available.
Given the router-broker with its two message-types:
RouterIn
RouterOut
The webproxy-broker has similar two message-types:
WebProxyIn
WebProxyOut
For the webproxy to be able to use the router, it has to connect to the input and output of the router. This happens with the following line:
web_proxy
.add_translator_link(
router,
Box::new(Self::link_proxy_router),
Box::new(Self::link_router_proxy),
)
.await?;
The link_proxy_router
and link_router_proxy
translate between the two messages, outputting
Option
s of the destination message.
This allows to connect the output of the webproxy with the input of the router, and the output
of the router with the input of the webproxy.
Now every time the router receives a message from the web, it will output it with a RouterOut
message.
All connected brokers to the router will receive this RouterOut
message, and translate it into
their internal messages.
The broker system will call the appropriate handlers to create output messages from the modules,
which will then be passed to RouterIn
, and back to the network.
This all happens in the background, both for libc
and wasm
compilation.