[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

Calling Runtime::getWorkerId() is only possible from within the
runtime, hence guard the call with CallerEnvironment.

[IO] set the affinity of Fibers created by the completer thread

See merge request i4/manycore/emper!188

Set the affinity for Fibers created from the completer thread
to the workerId where the completion originated from.

First, we split up the Callback type in a user facing and an internal one.
The internal one has a new affinity member which provides the memory for
the new Fibers affinity buffer. This is memory safe because the Callback
object is always heap allocated and freed when the CallbackFiber terminates.

Second, each Future has an affinity member as well which will be passed
to the BinaryPrivateSemaphore when calling signalFromAnywhere to
again hint the originating worker.

Both affinity values are set during the preparation of the Future in
IoContext::prepareFutureChain because then we are sure in which worker's
IoContext the completion will be generated.