In my master's thesis, I described in listing 4.4 an io_uring-based
suspension and notification algorithm, which is slightly different from
what emper does.

The described algorithm does not reset the sleep state if a worker
skips sleeping because of a global sleeper count of less than 0 (line 21).

Emper does always reset the sleep state to SleeperState::Running if
the sleep method returned early (either the worker was specifically
notified or the global sleep count indicated to skip the sleep attempt).

Both variants are sound, but invariably resetting the sleeper count to
running minimizes the windows of useless specific notifications.

However, the assertion in onNewWorkNotification assumes the sleep state
is always SleeperState::Notified if a specific notification is received
through the worker's io_uring.

Emper, resetting the sleep state, introduces a race between the notifier
observing the state as sleeping, setting it to notified, and posting a
notification to the potential sleeper's io_uring.
But the sleeper skips the sleep attempt because the global sleeper count
righteously resetting its state to running while invalidating the
assertion.

Therefore we remove the assertion because it is not invariant.

5.19 introduces new buffer opcodes thus the waitfd registration is
bumped.

When using IO_STEAL_ALL_ON_NOTIFICATION the stolen fiber pointer
was not initialized if no io continuations were stolen.
Fix this by always initializing it and deduplicate the
'reap all and schedule all but the first' logic.

Since 171ae9d4 we use are more recent
liburing version with io_uring_prep_msg_ring support.

I see no reason why punting is not always better.
Waitfd does not support NO_WAIT or poll therefore the request must be
always punted to the io_wq anyway.

The WaitfdSleepStrategy did not gather the amount of posted notifications
but the PipeSleepStrategy did.
Move the stats accounting into AbstractIoSleepStrategy so all derived
strategies track the amount of written notifications.

Set the user_data to NewWorkNotification on the MSG_RING cqe to detect
a possible failure (operation not supported by the kernel).

IOURING_OP_MSG_RING will creates two cqes on probably different rings.
We do not need the cqe on the submitting ring therefore skip its
generation and only track that on the messaged ring an additional cqe
is expected.

When the custom logic of the IO-based sleep strategies returns
false we already have set the sleeper state to Sleeping and must
reset it.

With Linux 5.18 io_uring supports sending notifications between io_urings.
This removes the need of writing to a specific eventfd to notify
specific sleeping workers.
This greatly reduces the complexity of the sued algorithm because
we do not longer need to prepare two sleeps in an atomic way.

The notify specific algorithm no can be similar to the one used by the
semaphore implementation.
The notifier sets the state of the specific worker to Notified and
if its was previously sleeping it is responsible to send a wakeup
message.

When a worker is going to sleep it sets its state to Running if
it was notified the state is reset and the sleep attempt skipped.
Otherwise a global read is prepared if needed and the worker waits
on its io_uring.

449 is futex_waitv since linux 5.16.

Eventfds are pollable (no iow thread is blocked reading from the IO object)
contrary to waitfds.
And using pipes seams also rather excessive especially since we ensure
that only a single notification is written before it is consumed.

This makes the code of the IO-based sleep strategies easier and I would
expect also faster.

Introduce AbstractIoSleepStrategy holding most of the code needed for
a sleep strategy using an IO object fur suspension/notification.

This changes are used in future patches to implement more IO-based
sleep strategies.

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

See merge request i4/manycore/emper!410

use liburing 2.2 wrap file provided via meson wrapdb

See merge request i4/manycore/emper!405

fix Future cancellation when using SINGLE_URING

See merge request i4/manycore/emper!407

When using the SINGLE_URING configuration the Future semaphore is used
to ensure that a forgotten Future is dropped after it is prepared and
not needed anymore.

Using the future after signaling its semaphore and thus allowing its
concurrent destruction is obviously broken.

Signal the semaphore after all preparation work is done.

Fixes: 9c0f2143

Fixes: 3fb3892b

[Semaphore] make default constructor more explicit

See merge request i4/manycore/emper!408

The CancelFutureTest fails for libc++ because it uses two
emper::Semaphores to coordinate the involved fibers.

Using gcc and stdlibc++ the default constructor initialized the
semaphore count to 0.

The default constructor using clang and libc++ does not initialize the
semaphore count member and thus causing the CancelFutureTest to misbehave.

Add the Big Fancy Pulser 9000 (BFP 9K) evaluation

See merge request i4/manycore/emper!397

[README] Fibirl uses spawn/sync as keywords (and no longer fork/join)

See merge request i4/manycore/emper!403