The value reported by std::thread::hardware_concurrency() can be more
than the available CPUs to the current process for example if EMPER runs
in a container or qemu.
GNU nproc(1) does the right thing and we can take inspiration from them.
The solution is to use pthread_getaffinity_np which fills a CPU set with
all CPU a pthread can be scheduled on.
We use this more precise CPU count if possible.

[gitlab-ci] Bump flowdalic/debian-testing-dev to 1.12

See merge request i4/manycore/emper!209

[Future] Fix clang-tidy issue in MadviseFuture

See merge request i4/manycore/emper!208

[gitlab-ci] Bump debian-testing-dev image to 1.10

See merge request i4/manycore/emper!199

[IO] add a madvise Future

See merge request i4/manycore/emper!206

Fix most llvm-12 clang-tidy warnings in IO code

See merge request i4/manycore/emper!205

Batch dequeue from AnywhereQueue

See merge request i4/manycore/emper!196

Thanks llvm 12 :)

errno was never set on error and thus the DIE_MSG_ERRNO did not properly
report what happened.

Found during changing Future member types.

The posix versions (close/openat) return int as well.
And this fixes a narrowing conversion in c_emper.cpp: emper_openat and emper_close

Use int32_t as Future returnValue instead of ssize_t since
io_uring uses int32_t not ssize_t as results value therefore it is
pointless to use a bigger type.

This shrinks the future size and prevents useless and implementation defined
narrowing conversions from ssize_t to int32_t.

Use union for flags and offset.

Ignore int to pointer cast clang-tidy warning.

[Debug] maybe-uninitialized should be ignored for gcc >= 11.1.0

See merge request i4/manycore/emper!204

[check-license] Do not pass --max-args to xargs

See merge request i4/manycore/emper!203

GCC 11.1 fixes

See merge request i4/manycore/emper!202

[CountingPrivateSemaphore] Fix assert

See merge request i4/manycore/emper!200

xargs: warning: options --max-args and --replace/-I/-i are mutually exclusive, ignoring previous --max-args value

gcc 11.1 on my arch system complains that the calls to free
does not match the allocator function new[].

As the code comment above the assert indicates, the atomic exchange
operation may either return nullptr or a valid Context pointer. And
this is what the assert() should assert. :)

Reported-by: Florian Fischer <florian.fl.fischer@fau.de>

[Common] Call abort() instead of exit() in die()

See merge request i4/manycore/emper!198

Calling abort() has multiple advantages. First, it better matches the
semantic of DIE(_MSG) as it signals an abnormal process termination,
whereas exit() is a normal process termination (even though
potentially with an error exit code). Secondly, abort() throws
SIGABRT, which in turn triggers a coredump, hence the program's state
can be inspected afterwards.

[LAWS/Fiber] Introduce the concept of Multi-Fiber

See merge request i4/manycore/emper!195

LAWS, and similar scheduling strategies, only need to perform
refcounting and atomic operations if the fiber was placed in multiple
ready-lists in the first place.

Already check if fiber is runnable in scheduliing subsystem

See merge request i4/manycore/emper!197

Already check if the fiber is in-fact runnable in the scheduling
subsystem. This should not make a difference when WS scheduling is
used, but makes a difference when LAWS is used.

[meson] propagate set_affinity_on_block

See merge request i4/manycore/emper!194

[LawsScheduler] Guard Runtime::getWorkerId() with CallerEnvironment

See merge request i4/manycore/emper!192

[IO] remove Future affinity awareness which is done in Blockable

See merge request i4/manycore/emper!193

Set affinity on block

See merge request i4/manycore/emper!191