internal.h File Reference

#include <stdatomic.h>
#include "serene/rt/context.h"
#include "serene/rt/fiber/thread.h"
#include "serene/rt/impl/pqmh.h"
#include "serene/rt/impl/spsc_ring.h"
#include "serene/rt/reactor.h"

Include dependency graph for internal.h:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Data Structures
struct	srn_reactor_io_channel_t
	A channel, the per-worker submission and completion ring pair. More...
struct	srn_reactor_t

Typedefs
typedef struct srn_reactor_io_channel_t	srn_reactor_io_channel_t
	A channel, the per-worker submission and completion ring pair.

Functions
void	srn_reactor_post_completion (srn_reactor_t *reactor, size_t channel, srn_reactor_io_completion_t completion)
	Post a finished operation to channel's completion queue and rouse the channel's worker through the notify mechanism.
srn_error_t *	srn_reactor_errors_static (srn_error_tag_t tag)
	Return the shared, immutable error for an IO failure tag.

Typedef Documentation

srn_reactor_io_channel_t

typedef struct srn_reactor_io_channel_t srn_reactor_io_channel_t

A channel, the per-worker submission and completion ring pair.

Function Documentation

srn_reactor_errors_static()

srn_error_t * srn_reactor_errors_static

(

srn_error_tag_t

tag

)

Return the shared, immutable error for an IO failure tag.

These live in static storage, not a context, so a completion or result can point one at maybe_error with no allocation and no lifetime concern, and it is safe to share across threads. A backend maps its native code (via srn_errno_to_tag on POSIX) to a tag, then to one of these. Any tag without a dedicated entry yields the UNKNOWN_IO_ERROR error.

Because they are shared they are never written to. In particular they are not trace targets, srn_error_trace_push, PUSH_TRACE and PUSH_AND_MOVE would allocate frames in one caller's context and record unrelated call sites into every later failure with the same tag. A caller that wants a trace on an IO failure builds its own error from the static one with ERR_FROM and traces that.

Definition at line 194 of file reactor.c.

                                                            {
 
  size_t count = sizeof(io_errors) / sizeof(io_errors[0]);
 
  for (size_t i = 0; i < count; i++) {
    if (io_errors[i].tag == tag) {
      return &io_errors[i];
    }
  }
  // the UNKNOWN_IO_ERROR fallback
  return &io_errors[count - 1];
}

Here is the caller graph for this function:

srn_reactor_post_completion()

void srn_reactor_post_completion	(	srn_reactor_t *	reactor,
		size_t	channel,
		srn_reactor_io_completion_t	completion )

Post a finished operation to channel's completion queue and rouse the channel's worker through the notify mechanism.

Runs on the reactor thread, called by the core for ops it completes itself (such as NOP) and by a backend when a descriptor operation finishes. It does NOT drop the in-flight count: that is the consumer's job via srn_reactor_op_done, so an op counts as gone only once the waiting fiber has been readied, never in the gap between.

Definition at line 210 of file reactor.c.

  {
  srn_reactor_io_channel_t *ch = &reactor->channels[channel];
  // Admission control bounds a channel's in-flight ops at the ring capacity,
  // and the op being posted is one of them and not yet in the CQ, so the CQ
  // always has a slot. A full CQ here means the accounting is broken; a spin
  // in its place would stall the whole reactor behind one busy worker.
  PANIC_IF(
    !srn_spsc_ring_push(ch->cq, &completion),
    "reactor: completion queue full despite admission control; this is a bug"
  );
 
  REACTOR_TRACEPOINT(
    reactor_complete, channel, completion.result, completion.maybe_error != nullptr,
    completion.fiber_data
  );
 
  // The in-flight count is dropped by the consumer through srn_reactor_op_done,
  // not here. A fiber's waiter must be readied before the op counts as gone, or
  // quiescence could fire in the gap between posting and readying.
  if (reactor->notify != nullptr) {
    reactor->notify(reactor->ctx->engine->scheduler, channel);
  }
}

Here is the call graph for this function:

Here is the caller graph for this function: