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.

[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.

First of all I think it makes sense for laws to also look at affinities of Fibers
scheduled to the AnywhereQueue.
But the actual reason is that IO completions scheduled from the completer
could be dispatched from the priorityQueue before they are found in the
expensive AnywhereQueue.

But this comes with the cost of a vcall for scheduleFromAnywhere.

Using the STL iterator based approach has caused more harm than it
has advantages.

First of all it is unneeded we know how the Fibers we want to schedule are stored
and don't need a algorithmic generic abstraction.

We keep Fibers pointers in continues memory for memory locality benefits
therefore we can simply use the C dynamic array style of passing the
Fibers to the scheduler.

This removes the template from the batched schedule methods and allows us
to use virtual functions to specialize the batched scheduleFromAnywhere
method.

[LAWS] Set fiber affinity *before* dispatching it, not after

See merge request i4/manycore/emper!189

[Blockable] Support worker affinity in PrivateSemaphore.signalFromAnywhere()

See merge request i4/manycore/emper!187

[EchoClient] don't include shutdown duration in echo duration

See merge request i4/manycore/emper!181

I do as IWYU guides.