Ensure that all std algorithms are implemented as parallel algorithms.

This README.md file is kind of old.

namespace c9y 
{
    template <typename IterT, typename Pred>
    void for_each(IterT begin, IterT end, Pred pred);
}

c9y::for_each is a parallel version of std::for_each. It executes the predicate for the sequence in multiple threads.

The following issues are open:

• partitioning
• number of threads
• reuse of a thread pool

latch::max may result in compile error if max is defined as a macro previously. Granted, this is the "fault" of the person including the header, but as a convenience undef the macro in the latch.h header.

For Linux and Mac support and integration into vcpkg configure CMake build environment.

The __cpp_lib_coroutine is false, even though it should be true. Investigate.

The API doc of c9y is not bad, but inconsistent and has some holes. Update it accordingly.

Implement basic CI using github actions.

void do_async(sigc::slot<void> func);

The do_async function takes a slot and executes this slot in a different thread. The main idea behind the function is to asynchronously execute bits of code with relative little coding overhead.

As a design constraint it may be assumed that the asynchronous slot will take a long time to execute and thus creating a new separate thread is feasible.

The clang version on github and vcpkg's azure devops does not have jthread. To help downstream libraries, write a drop in replacement for jthread.

Write a script that checks if all headers and sources are contained in the CMake file.

There was a design to implement std algorithms as async; node style. This would be a useful feature.

The reason why there are 2 pools is so that if a parallel algorithm is called from an async thread, it does not starve, since the thread itself does not work towards the parallel goal. The down side is that now you potentially have 2 times the hardware parallelism, which can lead to unnecessary contention.
To achieve this, thread must also work towards the parallel goal. The problem is it can't pick up any tasks, since tasks could potentially be long running.

Extend the parallel algorithms to the ranges library.

The Lock<Mutex> class is used quite often. But in external namespaces c9y::Lock<c9y::Mutex> is kind of verbatim it may be useful to introduce a typedef c9y::MutexLock.

Write documentation that is more comprehensive than the API doc. This is especially true for coroutines, since much of the code is only magic behind the scenes.

Description

The "catch all" header c9y.h does not include the entire library.

Steps to Reproduce

1. Include <c9y/c9y.h> into cpp file.
2. Try to reference c9y::sync_point

Expected

If the c9y.h header exists all (public) bits of the library should be made available; alternatively no catch all header should exist.

Observed

The c9y.h "catch all" header exists but only exposes a subset of the entire library.

Some scenarios do not want to wait to wait indefinably. We need to add an overload taking a timeout value in ms.

• update Changelog
• update version in defines.h
• update version in vcpkg.json
• update version in CMake

Update vcpkg.

Integrate learning of other build steps:

• nuget vcpkg cache
• put release and debug builds together (less vcpkg)
• add triplet to cache key

Yet an other bug resulting from a out of sync CMakeLists.txt: #81

Write a guthub ci script that checks the CMakeLists.txt either against the MSBuild files or the files present and report a build failure.

A Timer object is of good use.

c9y::latch is missing try_wait and arrive_and_wait

See:

The CMake build does not export properly the c9y::c9y package, which means you can't include it in CMake when using from vcpkg.

See: https://github.com/rioki/c9y/actions/runs/3021375601

The sync_func with once_tag does not foward the once_tag.

We need a ThreadPool class.