ldes_probe.h File Reference

Where the LDES engine is, and whether this machine can run it. More...

#include <cstdlib>
#include <fstream>
#include <string>
#include <vector>
#include <sys/stat.h>
#include <sys/utsname.h>
#include <unistd.h>

Include dependency graph for ldes_probe.h:

Go to the source code of this file.

Namespaces
namespace	line
namespace	line::ldes

Functions
const std::string &	line::ldes::ldes_engine_dir ()
	The directory holding the engine, or empty when there is none.
bool	line::ldes::ldes_is_available ()
	True when this machine can run the engine at all, by either image.

Detailed Description

Where the LDES engine is, and whether this machine can run it.

Its own header, small enough for SolverAUTO to include: LDES leads several of the reference's rankings, and the chooser needs to know whether the slot has an engine behind it without taking on the client, the result parser and the HTTP transport. This is lqns_probe.h's reason, and the same shape.

THE ANSWER IS CACHED for the life of the process: a binary does not appear or vanish mid-run, and the probe stats several directories and reads an ELF header, which SolverAUTO would otherwise repeat on every choice it makes.

TWO IMAGES, ONE ENGINE. common/ldes is an AOT GraalVM build and common/ldes.jar the same engine on a JVM; the AOT image starts faster and lacks the reflective features the JVM has, so the client tries it first and falls through. A binary built for ANOTHER CPU is skipped rather than run – the ELF e_machine says so before exec does – because the fall-through then still has the jar to reach, while an exec failure would look like an engine failure. When either architecture is unknown the binary is used as a best effort: an unknown is not evidence of a mismatch.

Definition in file ldes_probe.h.