Implemented an asyncify based implementation of asynchronous threading

[john-sharratt]

This pull request implements asynchronous threading

In essence what this does is allow the runtime to exit a WASM thread and resume it where it left off after an async condition passes - when coupled with the WASIX syscalls this allows for all waits and IO operations to unload their WASM threads when going idle.

In future this will allow a designer to move threads from one machine to another

Performed some benchmarks and asynchronous threading gives approximately a 6% increase in performance thus the benefits of parking idle threads appears to out way the overhead of managing them (tested with multiple runs).

before:

john@AlienWorld:/prog/deploy$ wrk -t 10 -c 600 -d 60 http://localhost:9080/
Running 1m test @ http://localhost:9080/
  10 threads and 600 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   203.43ms  335.09ms   1.87s    85.30%
    Req/Sec     1.38k   777.50     4.85k    71.05%
  750093 requests in 1.00m, 1.07GB read
Requests/sec:  12483.79
Transfer/sec:     18.24MB

after:

john@AlienWorld:/prog/deploy$ wrk -t 10 -c 600 -d 60 http://localhost:9080/
Running 1m test @ http://localhost:9080/
  10 threads and 600 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   125.93ms  209.33ms   1.41s    87.05%
    Req/Sec     1.38k   592.88     4.32k    73.30%
  798846 requests in 1.00m, 1.14GB read
Requests/sec:  13292.74
Transfer/sec:     19.42MB

[syrusakbary]

It looks good from me for the API side

[theduke]

I'm not so happy about putting more logic into the logic in binfactory/exec.rs, I really wanted to move away from that to make the logic less dependent on it.

Calls like WasiEnvBuilder::run() do not go through that flow.

We should but this into some reusable function , that preferably also does not require spawning threads.

[theduke]

Only did a supferficial review, more in-depth after we discuss it.

Also:

• needs some tests

[john-sharratt]

Only did a supferficial review, more in-depth after we discuss it.

Also:

• needs some tests

the snapshot tests already extensively test this (forking, http web server, etc...) - what we lack are tests in the JS area but that is not for this pull request

[john-sharratt]

Quite some refactoring to get the snapshot tests working - there were a number of edge cases that were failing

Completed this round of review

[john-sharratt]

Tests have been added in snapshots

[syrusakbary]

Looks good to me from the API side

[theduke]

This is only partial, final review to come.

[syrusakbary]

LGTM on the API side