Commit some funky docs
parent: tbd commit: c4cba92
Showing 2 changed files with 95 insertions and 0 deletions
docs/ABI.md
| @@ -0,0 +1,81 @@ | ||
| 1 | # ABI | |
| 2 | ||
| 3 | ## Value ABI | |
| 4 | ||
| 5 | At its core, the Giterated Runtime uses the `extern "C"` ABI. What that means is likely platform specific, and doesn't matter. | |
| 6 | You are intended to compile the Giterated Runtime and Plugins for your local machine, all with a similar idea of what | |
| 7 | your "local machine" is. | |
| 8 | ||
| 9 | Values are passed using the `FFI` type. There are four categories of value that the `FFI` type enables you to pass: | |
| 10 | ||
| 11 | | `FFI` Type Category | Placed Backing? | Owned? | | |
| 12 | |---------------------|-----------------|--------| | |
| 13 | | Slice | Heap/Stack | No | | |
| 14 | | Referenced Slice | Stack | No | | |
| 15 | | Referenced Value | No | No | | |
| 16 | | Owned Value | Heap | Yes | | |
| 17 | ||
| 18 | For an FFI type to have a "placed backing" is for it to have some data structure beyond the data it represents, placed | |
| 19 | somewhere in memory. Some types only require stack placement while some offer both stack and heap placement. | |
| 20 | ||
| 21 | Stack-placed values can be shared by `PinnedRef` and `PinnedMut`, and thus can only be owned by the caller. | |
| 22 | ||
| 23 | Heap-placed values can be shared by `Owned`, `PinnedRef`, and `PinnedMut`. They can be owned by any one consumer, | |
| 24 | When the handle with ownership is `Drop`'d by the sole consumer, it will free the object using the associated `Drop` callback. | |
| 25 | ||
| 26 | ### Safety Intents | |
| 27 | ||
| 28 | This API is designed to simplify interaction with FFI values, and provide a static ABI for those values to be passed. It | |
| 29 | is key to enabling ownership across FFI while ensuring associated dropping and allocation freeing logic is ran. | |
| 30 | ||
| 31 | The contract the developer has to follow is made simpler by this system, and it allows for generic code to be written to | |
| 32 | interact with FFI-given values and pass values using FFI. | |
| 33 | ||
| 34 | ### Stability Guarantees | |
| 35 | ||
| 36 | There are no plans to guarantee stability until 1.0.0. At that point you can expect the ABI to remain stable until the major version | |
| 37 | is incremented again. There will be an appropriate deprecation process and changeover period. | |
| 38 | ||
| 39 | ### Memory Representation | |
| 40 | ||
| 41 | Please check out the source code, sorry if you needed that from the docs! | |
| 42 | ||
| 43 | ## Object, Operation, Setting, Value, Plugin, and Runtime ABIs | |
| 44 | ||
| 45 | The Giterated Runtime uses vtables to accomplish the goal of ensuring maximum compatibility. For every object that is shared | |
| 46 | between plugins, a vtable is used to allow each plugin to provide their own code for interacting with the object. | |
| 47 | ||
| 48 | When objects switch "runtime domains" (e.g. host -> plugin, plugin -> plugin, plugin -> host), their vtable is swapped out | |
| 49 | for the new runtime domain's own vtables. | |
| 50 | ||
| 51 | ### Untyped "Objects" (see above header for list) | |
| 52 | ||
| 53 | Untyped objects, in memory, are represented by a data pointer and a vtable pointer. Exactly like Rust traits. However, to | |
| 54 | prevent small compilation differences and other random garbage from making the interface not perfectly compatible we use | |
| 55 | the local plugin's idea of the vtable for the object at all times. An object that the plugin does not have a vtable for cannot | |
| 56 | be relevant to the plugin. | |
| 57 | ||
| 58 | It is important that the object's base representation in memory remain unchanged between major versions, but the vtables that provide methods for | |
| 59 | that object may be grown. The methods that operate on that object may be changed in an non-breaking fashion, and bugs can be | |
| 60 | fixed. | |
| 61 | ||
| 62 | ## Futures ABI | |
| 63 | ||
| 64 | The Giterated Runtime has an async runtime that allows for futures to be shared and awaited across FFI boundaries while only | |
| 65 | executing the future within the context of the Plugin who is running the underlying future. | |
| 66 | ||
| 67 | Futures are spawned onto the `RuntimeState` with the `RuntimeFuturesExt` trait. This takes a Rust future, boxes it, and | |
| 68 | provides a `RuntimeFuture` handle that can be used to drive the underlying Rust future locally. The `RuntimeFuture` handle | |
| 69 | is thread-safe and can be shared with the callee and `.await`'d directly like any other future. | |
| 70 | ||
| 71 | ### RuntimeFuture | |
| 72 | ||
| 73 | The `RuntimeFuture` mixes a vtable with data to allow for any caller to drive a spawned future. It contains: | |
| 74 | ||
| 75 | - A `poll_fn` which is used to poll the future for `Ready`-ness | |
| 76 | - A `wake_fn` which is used to wake the callee to poll for (expected) `Ready`-ness, it is populated when the `RuntimeFuture` is `await`'d. | |
| 77 | ||
| 78 | When the `RuntimeFuture` is polled, it causes the inner future to also be polled. We provide the inner future with a waker | |
| 79 | that triggers the `RuntimeFuture`'s waker so it is polled again. Breaking character to point out how freaking cool that is. | |
| 80 | ||
| 81 | `RuntimeFuture`s drop the associated inner future as they drop. | |
| 81 | \ No newline at end of file | |
docs/PLUGINS.md
| @@ -0,0 +1,14 @@ | ||
| 1 | # Plugins | |
| 2 | ||
| 3 | The Giterated Runtime does nothing on its own. Plugins are what bring functionality and logic which the Runtime executes. | |
| 4 | ||
| 5 | Plugins can be written in any language that can be compatible with the ABI and API set by the Giterated Runtime. There is no | |
| 6 | hard requirement that the plugins need to be developed with Rust, but as of the time of writing this document that is the only | |
| 7 | intended first-party supported language on the roadmap. The design seems relatively friendly for other languages to meet. | |
| 8 | ||
| 9 | ## [The ABI](ABI.md) | |
| 10 | ||
| 11 | ## The API | |
| 12 | ||
| 13 | The Giterated Runtime uses a set of standard function identifiers which it attempts to dynamically resolve from the Plugin's | |
| 14 | binary. | |
| 14 | \ No newline at end of file | |