* Update docs on io_scheduler for inline processing
Support gcc 10.3.1 (fedora 33 updated)
Update ci.yml to run fedora 32,33,34 and support both
gcc 10.2.1 and 10.3.1
* fedora 32 -> gcc-c++ drop version
* Update ci.yml and test_latch.cpp
* io_scheduler uses thread pool to schedule work
fixes#41
* use task_container in bench tcp server test
* adjust benchmark for github actions CI
* fix io_scheduler tests cross thread memory boundaries
* more memory barriers
* sprinkle some shutdowns in there
* update readme
The scheduler had a 'nice' optimization where any newly
submitted or resumed task would try and check if the current
thread its executing was the process event thread and if so
directly start or resume the task rather than pushing it into
the FIFO queues. Well this has a bad side effect of a recursive
task which generates sub tasks will eventually cause a
stackoverflow to occur. To avoid this the tasks for
submitting and resuming go through the normal FIFO queue which
is slower but removes the recursive function calls.
Turns out that the final_suspend() method is required
to be std::suspend_always() otherwise the coroutine_handle<>.done()
function will not trigger properly. Refactored the task class
to allow the user to decide if they want to suspend at the beginning
but it now forces a suspend at the end to guarantee that
task.is_ready() will work properly.
