# Lunatic Releases
---
## v0.7.0
Released 2021-12-01.
### Changes
This is the first release that supports connecting multiple lunatic instances togethe :tada:.
From the perspective of developers that are targeting lunatic there should be no difference
between locally running processes or remote ones. Spawning and sending messages to them uses the
same APIs.
To turn your local lunatic instance into a distributed node you will need to provide an unique
_name_ and _socket_ to bind to. Both of them can be set through the cli.
#### CLI
To start a distributed node you can run:
```
lunatic --node 0.0.0.0:8333 --node-name foo --no-entry
```
This starts a lunatic node with the name `foo` listening the specified port. The `--no-entry` flag
means that this node doesn't have a start function, it will just block forever.
If you want to connect to a node you can pass in the `--peer` flag:
```
lunatic --node localhost:8334 --node-name bar --peer 0.0.0.0:8333 file.wasm
```
Once you connect to one node all others known ones will be dynamically discovered.
#### Usage from guest code (Rust)
A great thing about lunatic is that much of the functionality provided by the runtime is directly
exposed to the code running inside of it. This allows you to dynamically load WebAssembly code
from already running WebAssembly code, or to create sandboxed environments to execute some code
on the fly.
The abstraction of an [`Environment`][18], that we used previously to sandbox and limit process
resources, fits perfectly into the world of distributed lunatic. Every time you create a new
`Environment` you need to explicitly add Wasm [`Modules`][19] to it, because we may need to JIT
re-compile the module with the new limitations that have been set. Spawning a process from the same
function in different `Environments` may use different machine generated code to be more efficient
in regards to the provided sandbox.
Now that a `Module` may be sent over the network to a computer running a different operating system
or even using a different CPU architecture, no changes need to be done to this already existing
pattern inside of lunatic.
Here is an example of using the new API from Rust guest code:
```rust
use lunatic::{Config, Environment, Mailbox};
#[lunatic::main]
fn main(_: Mailbox<()>) {
// Give full access to the remote environment.
let mut config = Config::new(0xA00000000, None);
config.allow_namespace("");
// Create a new environment on the remote node with the name "foo"
let mut env = Environment::new_remote("foo", config).unwrap();
// Add the currently running module to the environment.
// This allows us to spawn a process from a closure, because the remote module will have the same
// bytecode available.
let module = env.add_this_module().unwrap();
// Spawn a process on a remote machine as you would do it locally.
Instead of dealing with low level pointers + lengths passed from the WebAssembly guests, we can _pretend_
to receive higher level Rust type (e.g. `&mut [IoSliceMut<'_>]`) and the macro is going to create appropriate
wrappers for us. And of course, it correctly works with `async` functions on Lunatic.
This was an important step forward to make Lunatic runtime agnostic. Currently we support bot Wasmer and Wasmtime,
but if we wanted, we could add support for another runtime in the future by just adding support to `uptown_funk`.
Sadly, `uptown_funk` doesn't have any documentation yet and is not that useful to other projects. But I intend to
invest more time into this in the future.
#### 2. Fixed Process canceling cleanup
This issue needs a bit context. All Lunatic processes are executed on a separate stack and if they are waiting
for some I/O they will be moved off the execution thread. Now, you can decide while you are waiting on something
just to cancel this process. Until now this would free the memory region belonging to the stack/heap and finish.
However, it can happen that the separate stack contains pointers to resources held by the runtime (channels, other
processes, etc.). Their `drop()` methods would never have been called in this case and the resources would have
been leaked.
This required [a fix](https://github.com/bkolobara/async-wormhole/commit/be7a91ba621c41b49bc834d49479f51c4487cc47)
in the [async-wormhole](https://github.com/bkolobara/async-wormhole) crate. Now, every time when a generator is
dropped and the closure didn't yet finish running, a stack unwind will be triggered on the separate stack. This
will clean up all the resources left behind.
#### 3. Updated Rust's library
The [Lunatic Rust library](https://crates.io/crates/lunatic) allows you to write Rust applications that can take
complete advantage of Lunatic's features, not to embed the Lunatic runtime in your Rust application (coming soon).
The Rust library has seen almost a complete rewrite and takes much better advantage of Rust's ownership model now.
Especially when sending host resources between processes.
#### 4. Added initial WASI filesystem support
This is still a WIP area, but the basic functionality is there for opening files, reading directories, etc.
#### 5. Added TCP support
A few APIs are still missing, but we have enough to create a TCP listener/client.
#### 6. Miscellaneous fixes
There are too many other small fixes and additions to mention here, but Lunatic is much more stable now than just
2 months ago and I have removed the experimental warning in the Readme :)