pddl_planner
Functions
Main.cpp File Reference
#include <iostream>
#include <fstream>
#include <stdio.h>
#include <map>
#include <set>
#include <errno.h>
#include <cstring>
#include <cstdlib>
#include <unistd.h>
#include <pddl_planner/Planning.hpp>
#include <boost/program_options.hpp>
#include <boost/tokenizer.hpp>
#include <boost/algorithm/string.hpp>

Functions

void usage (int argc, char **argv, const pddl_planner::Planning &planning)
 
std::string readFile (const std::string &filename)
 
int main (int argc, char **argv)
 

Function Documentation

◆ main()

int main ( int  argc,
char **  argv 
)

◆ readFile()

std::string readFile ( const std::string &  filename)

◆ usage()

void usage ( int  argc,
char **  argv,
const pddl_planner::Planning planning 
)

Main test script for the pddl_planner component

usage:

./pddl_planner [-p <planner-name>] [-t <timeout-seconds(float)>] <domain-description-file> <problem-file> OR: – usage:

./pddl_planner [-l <# of planners> <planner-name> <planner-name> ... ] [-t <timeout-seconds(float)>] [-s] <domain-description-file> <problem-file> [-s, –sequential]

Parallel execution of planners is default, but use -s option to run listed planners sequentially, i.e. not using threads.

Rationale for using threads:

  • threads created in the main function have access to the common global string variable 'output'; - it is more convenient to carefully append (!concurrency issues!) each individual planner execution result to the 'output', rather than redirecting the standard output of the planners to a common location, later on reading it again - functionality to read the plan files is already implemented at the planners level and their common interface (PDDLPlannerInterface), the level where the filenames and locations of the result plans are known. --—
  • synchronizing the waiting for results is simpler and more reliable when using the threads API (i.e. simply joining the individual threads) rather than sending signals around from forked child processes (the ones dealing with individual planners) back to the main process (their common parent)
  • threads are much more time and memory efficient (they share the same memory, switching between threads is much faster for the scheduler than switching between processes and so)