… again

…tuations

Prevent creating a new tokio runtime all the time

… changes

… polling loop

…ng an event when it should not have been, causing an infiinte loop

Was introduced by recent refactoring

Because everything should have a Debug impl...

Resolves the TODO, and really needed to be done...

Because the manual implementation causes clippy warnings

Tokio 1.23 has a CVE, so update to 1.24

License can't be auto-detected, so it needs a manual clarification.

Crate doesn't have any of the compiler features...

…ents on new connections in certain race conditions

Align with master on two changes which were probably accidentally
screwed up during a merge or rebase.

This commit adds a total task (aka thread) limit for a WasiControlPlane.

The limit is configured at startup, and is checked whenever a new
process or a new thread is created.

The major breaking change is that the new_process and new_thread methods
are now fallible and return an error.

Also adds two tests that validate the limits are repsected.

Along with this feature the commit also does some cleanup and reafactoring:

* Simplify WasiControlPlane

It was using multiple Arcs with locks and atomics with no real justification.
The state is only locked for very short periods, so the complicated
setup doesn't yield any benefits.

The mutable state is consolidated behind a single RwLock, which holds the
process id seed and the process map, and the whole type is behind a
single Arc.

The reservations are removed, since they are not really useful if the
state is only locked for very short periods.

Also adds todo notes for handling pid exhaustion and process de-registration.

* TaskJoinHandle

Adds a new TaskJoinHandle handle that is used by both processes and threads
to track termination.

Replaces a complex, cryptic type.

* Simplify Thread state and make it private

Make internal thread state private to better encapsulate the code.
Also restructures the type to be behind a single Arc instead of multiple
redundant Arcs.

NOTE: should also be done for WasiProcess

Adds a test for the custom memory computation that is currently
commented out.

Mostly here for testing purposes, should be removed again.

Co-authored-by: Syrus Akbary <[email protected]>

This crate will hold utility functionality that doesn't fit well
anywhere else.

It is primarily used by Deploy and doesn't really belong in wasi.

Deletes a tokio + tungstenite based Websocket implementation in the wasi
crate.

The file wasn't even included in the module tree.

The code is moved to the wasmer-sys-utils crate, but commented out at
the moment.

Should probably just be removed.

It fits better there!

Move the WasiDummyWaker to the utils module, since it doesn't really
belong in the state module.

Also adds a comment explaining what it does.

Because an outdated comment is the worst kind of comment.

fd_mmap_memory was moved there previously

Mostly just cosmetic stuff.

On non-trivial change: changed WasiPipe to have a wrapper subtype for
the reader, which includes the channel and the buffer.

Previously buffers were constructed with Vec::with_capacity and
Vec::set_len, which creates unitialized memory.

The buffers were then passed along outside of the unsafe context.

This is unsound.

Ideally we would do something more fancy with MaybeUninit, but just
creating the buffer with zeroed out memory is enough for now.

Enable tokio runtime feature for tests, remove some definitions that are
not defined on js, ...

Always required now , not just when the compiler feature is on.

Only intended for wasm32- targets

(not working properly at the moment)

Was usually enabled ephemerally.

Need to use WasiBidirectionalPipePair to allow accessing the stdout/stderr.

Initialization is required, but was apparently removed from the CLI run
code previously.

File is an artifact of a big rebase, not needed any longer.

Was previously used in the SSH shell.

Define a const for the poll_write_ready buffer size hint, and add some
explanation about the chosen number.

Was previously sorted by modification time, which is not terribly
deterministic and problematic to sort on in tests.

The accessed time can/will change after a rename, which is correct
behaviour.
This wasn't accounted for in the test.

a) much more readable this way
b) silences clippy

- Removed the need to clone WasiEnv whenever signals are processed
- Modified the poll_oneoff syscall so that it works with polls rather than Boxed futures
- Removed the mpsc channel in poll_oneoff

- WasiImplementation now returns a refernce to the tokio runtime
- block_on no longer needs sync or send
- Removed the mpsc channels which are no longer needed

Removes the websocket support from wasix.

Websockets are a high level concept.
They should not be integrated so deeply into the core of wasix.

For client connections, we will want to add support for websocket
clients into the custom wasix_http_client bindings.

For servers, the support should go into the custom wcgi server bindings.

- Avoiding a memory copy on all socket reads and writes using a new `copy_from_slice` instead
- File openers no longer box the implementation avoiding a memory allocation on all file access
- Polling sockets rather than using an async function which significantly reduces locking contention and removes an box operation
- Futex now uses wakers rather than broadcasts which makes them more efficient and durable
- Converted many async functions into sync functions in vnet
- Sleeping no longer allocates memory
- Avoiding a number of WasiEnv clones which was impacting performance and memory efficiency

- Avoiding a memory copy on all socket reads and writes using a new `copy_from_slice` instead
- File openers no longer box the implementation avoiding a memory allocation on all file access
- Polling sockets rather than using an async function which significantly reduces locking contention and removes an box operation
- Futex now uses wakers rather than broadcasts which makes them more efficient and durable
- Converted many async functions into sync functions in vnet
- Sleeping no longer allocates memory
- Avoiding a number of WasiEnv clones which was impacting performance and memory efficiency

Preparation for removing the two-step construction with WasiState and
WasiEnv

The crate provides an abstraction layer that we currently don't yet need
or want.

The vbus types are used quite a bit in other consumers, but follow ups
should remove a lot of the Vbus type/abstractions.

They can always be added back later.

type Result<_, MyError> aliases add lots of confusion to code, best to
just strip it out.

First step in improving the wasi module construction flow.
Lots of steps to follow.

The WasiState was only stored on the BinFactory for one small
functionality, accessing the file system.
This is much easier handled by passing in the relevant filesystem to the
get_binary function.

Achieves a much more sensible separation of state.

…task_wasm

Simplifies module construction