sequencer_service — state machine, actuator commanding, abort, FIRE lifecycle. More...

Functions
void	signalHandler (int)
std::string	trim (const std::string &s)
void	handleCommandLine (int client_fd, const std::string &raw, sequencer::SequencerService &svc)
	Execute one newline-terminated command and write its reply.
void	handleClient (int client_fd, sequencer::SequencerService &svc)
	One connection, on its own thread: read lines, dispatch, reply, until the peer closes.

Variables
std::atomic< bool >	g_running {true}
constexpr size_t	kMaxClients = 64
constexpr size_t	kMaxLineBytes = 512

Detailed Description

sequencer_service — state machine, actuator commanding, abort, FIRE lifecycle.

Listens on TCP (default port 9998) for newline-terminated text commands:

TRANSITION:<state_name>[:<ms>] — request state transition; the optional duration overrides the hold of a state configured to accept one (never the burn state — that is refused) ACTUATOR:<role_name>:<0|1> — manual actuator command (debug mode only) DEBUG_MODE:<0|1> — toggle debug mode EXTEND_FIRE — extend FIRE window SCRIPTS — read-only: what this process made of its dynamic states at startup (loaded, or refused and why). A query, not a push; the answer is fixed for the life of the run.

There is deliberately no reload command. Config reaches this process once, at startup: the backend deploys the active profile to config/ at session start and then the pipeline units are started, so a running sequencer's config is frozen for the life of the run.

Each command gets an immediate reply of "OK\n" or "ERR:<reason>\n". Multiple simultaneous TCP clients are supported (a bounded, joined thread per connection). Commands are not executed on those threads: each is posted to SequencerService's command queue and run by its single worker, which is what serializes access to the state machine.

Usage: ./sequencer_service [–config PATH] [–port PORT]

Function Documentation

◆ handleClient()

void anonymous_namespace{sequencer_main.cpp}::handleClient	(	int	client_fd,
		sequencer::SequencerService &	svc )

One connection, on its own thread: read lines, dispatch, reply, until the peer closes.

A thread per connection looks redundant now that SequencerService serializes everything on its worker — and an earlier revision of this change did fold it into the accept loop. A stress run showed why that was wrong: while the loop sits inside a command waiting for the worker, it is not calling accept(), so new connections queue in the backlog and time out at the client even though the service itself is healthy (600 concurrent transitions: 0 service-side timeouts, 5 client-side ones, all of them accept latency). Serializing execution is the goal; serializing acceptance was an accident.

What the old version got wrong was not the threads, it was their lifetime: they were detached while holding a reference to a stack-allocated service, so they could outlive it at shutdown, and nothing bounded how many existed. Both are handled by the caller now — threads are counted and joined.

Definition at line 197 of file sequencer_main.cpp.

References g_running, handleCommandLine(), and kMaxLineBytes.

Referenced by main().

◆ handleCommandLine()

void anonymous_namespace{sequencer_main.cpp}::handleCommandLine	(	int	client_fd,
		const std::string &	raw,
		sequencer::SequencerService &	svc )

Execute one newline-terminated command and write its reply.

Does no state-machine work itself: every command below is posted to SequencerService's command queue and executed by its single worker thread, which is what serializes them. This function parses, dispatches, and replies.

Definition at line 73 of file sequencer_main.cpp.

References sequencer::SequencerService::extendFire(), sequencer::SequencerService::manualActuator(), sequencer::parseHoldMs(), sequencer::SequencerService::scriptStatusReport(), send(), sequencer::SequencerService::setDebugMode(), sequencer::SequencerService::transitionTo(), and trim().

Referenced by handleClient().

◆ signalHandler()

void anonymous_namespace{sequencer_main.cpp}::signalHandler ( int )

Definition at line 55 of file sequencer_main.cpp.

References g_running.

◆ trim()

std::string anonymous_namespace{sequencer_main.cpp}::trim ( const std::string & s )

Definition at line 60 of file sequencer_main.cpp.

References a, and b.

Referenced by handleCommandLine().

Variable Documentation

◆ g_running

std::atomic<bool> anonymous_namespace{sequencer_main.cpp}::g_running {true}

Definition at line 46 of file sequencer_main.cpp.

Referenced by handleClient(), and signalHandler().

◆ kMaxClients

size_t anonymous_namespace{sequencer_main.cpp}::kMaxClients = 64

constexpr

Definition at line 51 of file sequencer_main.cpp.