Не знаю как у вас, но у меня обычно, когда мне нужно, что-то написать с нуля начинается лихорадка и полная прострация в мыслях. В голове уже летают различные абстрактные модели, что от чего и куда. Но ни за одну из них ухватиться не получается, потому что перед тобой чистый лист и вырвав из головы одну мысль, применить ее не к чему, а вытащить весь скелет не получается потому, что ты уже думаешь о решении задачи, а тебе еще только нужно написать костяк приложения.
Ниже представлен «проект NULL», тот самый костяк, с которого обычно все и начинается. У меня.
Данный пост скорее всего не будет интересен тем кто уже матерый и тем кто на прямую не связан с разработкой на С++, т.к. ниже представленные материл несет одну единственную цель — дать готовый фундамент для начала.
Попробую для начала выделить ряд требований которые было бы неплохо реализовать в этом костяке
Цель скрипта gen_eclipse.sh это подготовить структуру папок и вызвать cmake для генерации debug и release солюшинов. А так же задать текущую версию проекта. Так сложилось, что разработка на Linux системах у меня обычно ведется в среде Eclipse, отсюда и название gen_eclipse. Но полноценно сдружить Cmake и Eclipse у меня так и не получилось. Для того, что бы сгенерированный проект открыть в Eclipse нужно сделать импорт уже существующего MAKE проекта, при том или release или debug, и через контекстное меню добавить ссылки на директории include и src.
Первое что стоит отметить, это то, что я использую Subversion и в качестве версий полагаюсь на номера ревизий. Я обычно придерживаюсь следующего формата версии: MAJOR.MINOR.REVISION. Первые два значение задаются ручками, третий это ревизия svn. Насколько мне известно, клиент subversion не умеет возвращать просто номер ревизии, поэтому я использую следующий механизм
Как правило, весь софт, который приходилось писать под Linux, это были сервера, большие и маленькие. Особенность их в том, что они работают в фоне, это службы. Я знаю, что для таких вещей принято иметь в директории init.d скрипты запуска и останова. Но! У меня еще не было ни одного случая, когда на одном сервере запускали бы только одну версию службы. Поэтому я придерживаюсь практики start stop скриптов с контролем по PID файлу.
Скрипт останова имеет куда более изощренную логику, для медленного останова сервера.
PS. Спасибо моему коллеге Андрею за то, что предложил более юзабельную версию скрипта stop.sh
В каждом из проектов у меня есть скрипт package.sh цель которого, создать достаточный инсталляционный пакет. Как правило это заархивированная папка приложения с набором файлов достаточным для работы приложения. Минимальный набор это скприты запуска останова, конфигурационный файл, само приложение, и папка для логов.
И так, что же мне обычно нужно, что бы приступить непосредственно к программированию:
Начнем по порядку:
Я выделил для себя три таких параметра. Сейчас я попробую объяснить, почему именно они.
Директория для логирования. Причина, по которой я не храню этот параметр в конфигурационном файле, это то, что в процессе разбора конфигурационного файла уже могут случиться ошибки, которые я хочу логировать. Почему директория? Я привык, что каждый запуск это отдельный лог файл, таким образом, легче удалять старые логи.
Конфигурационный файл Если не через командную строку, то как? Особенно если у вас несколько конфигураций, которые вы хотите быстро переключать.
PID файл. Единственная причина, почему я не храню его в конфигурационном файле это то, что данный параметр используется сразу в 2 местах. В start и stop скриптах. И гораздо проще вынести его в отдельный файл init, который подключается к start stop скриптам, и править его один раз, чем два (я про conf файл).
Разбор командной строки и файла конфигурации, производится средствами boost::program_options
Каждый из параметров имеет значения по умолчанию
Я не стал изобретать свой логгер, как правило, в каждой фирме он свой. В данном проекте я ограничился выводом в консоль, в режимах Note и Error. Единственно требование, которое я предъявляю к логгеру это то, что он должен поддерживать интерфейс подобный printf. Согласитесь со мной ведь printf это прекрасно. Я лишь добавил макросы для удобного процесса логирования.
На мой взгляд, корректная остановка, это одна из важнейших функций ПО о которой часто забывают. Как правило, сделать корректную остановку в уже разработанном ПО это непосильная задача. Другое дело, если придерживаться определенной стратегии с самого начала, то это становится пустяком. Я не рассматриваю всякие изощренные способы получения команды останова по сети, по SMS или через спутник. Я просто ловлю некоторые сигналы, после чего инициирую процедуру корректного останова.
Единственное что требуется это вызвать функцию wait_exit() в главном потоке, после выполнения всех активный действий.
Спасибо mejedi за указание некорректности использования обработчика сигналов для данных нужд. Надеюсь я правильно истолковал(реализовал) ваше предложение.
Вот мы и добрались к финальной части. Как уже многим стало ясно, я использую паттерн «Медиатор». Конечно, не во всей его красе, ибо никакой бизнес логики пока нет.
Если какую то работу предполагается выполнять в отдельном потоке, то для такой задачи должен существовать отдельный класс, унаследованный от специального класса Thread.
Цель которого поддержать в едином формате процесс запуска и останова.
Проект доступен в Google Code, но только для read-only. Это не потому что я жадный, я просто не знаю как открыть доступ для всех. При желании вносить правки, пишите ваш g-email, добавлю вас к проекту.
Идея оформить данную наработку в осязаемый шаблон возникла у меня месяца два назад, в процессе очередного проекта который нужно было слобзать быстро и с чистого листа. В ходе написания проекта я пришел к выводу, что это уже не первый раз, когда у меня получается подобная архитектура, и что нет смысла каждый раз вспоминать все подводные камни и приходить к тому же решению, которое использовал раньше, нужно оформить его как шаблон. Я долго мучился на счет целесообразности написания этой статьи, но вспомнив притчу про учителя и стакан воды, я решил, что лучше мне скажут, что статья не стоит и ломаного гроша, чем я буду продолжать думать о ее целесообразности.
Спасибо за внимание.
PS. Добавлены различные проверки PID файла при запуске. Обрабатываются кейсы файл с PID есть — процесса нет, PID файл пустой.
Ниже представлен «проект NULL», тот самый костяк, с которого обычно все и начинается. У меня.
Данный пост скорее всего не будет интересен тем кто уже матерый и тем кто на прямую не связан с разработкой на С++, т.к. ниже представленные материл несет одну единственную цель — дать готовый фундамент для начала.
Требования
Попробую для начала выделить ряд требований которые было бы неплохо реализовать в этом костяке
- Проектная папка
- скрипты сборки CMake и скрипты для генерации солюшинов
- скрипты запуска и останова
- приложение должно стартовать, работать и корректно завершаться, весь этот процесс должен логироваться
- логировать можно и в консоль, все равно в каждом проекте свой логгер, главное, что бы его было легко заменить.
- приложение должно разбирать командную строку
- приложение должно уметь разбирать конфигурационный файл вида key = value
- проект без boost? не, не слышал. Так что сразу интегрируем boost
- обработка ошибок. Так как это только костяк и тут, по сути, никакого перформенса нет, то делаем на исключениях.
делаем функцию захвата мира
Проектная папка
.
├── CMakeLists.txt
├── gen_eclipse.sh
├── include
│ ├── logger.h
│ ├── mediator.h
│ ├── pid.h
│ ├── program_options.h
│ ├── thread.h
│ └── version.h
├── package.sh
├── src
│ ├── logger.cpp
│ ├── main.cpp
│ ├── mediator.cpp
│ ├── pid.cpp
│ ├── program_options.cpp
│ └── version.cpp
├── start.sh
├── stop.sh
└── version.sh
Генератор солюшинов
Цель скрипта gen_eclipse.sh это подготовить структуру папок и вызвать cmake для генерации debug и release солюшинов. А так же задать текущую версию проекта. Так сложилось, что разработка на Linux системах у меня обычно ведется в среде Eclipse, отсюда и название gen_eclipse. Но полноценно сдружить Cmake и Eclipse у меня так и не получилось. Для того, что бы сгенерированный проект открыть в Eclipse нужно сделать импорт уже существующего MAKE проекта, при том или release или debug, и через контекстное меню добавить ссылки на директории include и src.
gen_eclipse.sh
#!/bin/bash
ROOT_DIR=$PWD
BUILD_DIR=$PWD/"build"
BUILD_DIR_R=$BUILD_DIR/release
BUILD_DIR_D=$BUILD_DIR/debug
mkdir -p $BUILD_DIR
mkdir -p $BUILD_DIR_R
mkdir -p $BUILD_DIR_D
if [ -d $BUILD_DIR_R ]; then
if [ -f $BUILD_DIR_R/CMakeCache.txt ]; then
rm $BUILD_DIR_R/CMakeCache.txt
fi
fi
if [ -d $BUILD_DIR_D ]; then
if [ -f $BUILD_DIR_D/CMakeCache.txt ]; then
rm $BUILD_DIR_D/CMakeCache.txt
fi
fi
echo "[[ Generate Release solution]]"
cd $BUILD_DIR_R
cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE:STRING="Release" --build $BUILD_DIR_R ../../
echo
echo "[[ Generate Debug solution]]"
cd $BUILD_DIR_D
cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE:STRING="Debug" --build $BUILD_DIR_D ../../
cd $ROOT_DIR
./version.sh
Версия
Первое что стоит отметить, это то, что я использую Subversion и в качестве версий полагаюсь на номера ревизий. Я обычно придерживаюсь следующего формата версии: MAJOR.MINOR.REVISION. Первые два значение задаются ручками, третий это ревизия svn. Насколько мне известно, клиент subversion не умеет возвращать просто номер ревизии, поэтому я использую следующий механизм
REVISION=`LANG=C svn info | grep "Last Changed Rev:" | sed s/"Last Changed Rev":\ //`
if [[ "$REVISION" == "" ]]; then
echo "Cannot recognize number of revision"
exit 1
fi
...
VER_CPP=src/version.cpp
echo "#include \"version.h\"" > $VER_CPP
echo "const char* VERSION = \"$VERSION\";" >> $VER_CPP
Скрипты запуска, останова
Как правило, весь софт, который приходилось писать под Linux, это были сервера, большие и маленькие. Особенность их в том, что они работают в фоне, это службы. Я знаю, что для таких вещей принято иметь в директории init.d скрипты запуска и останова. Но! У меня еще не было ни одного случая, когда на одном сервере запускали бы только одну версию службы. Поэтому я придерживаюсь практики start stop скриптов с контролем по PID файлу.
start.sh
#!/bin/bash
source init.conf
MAIN_LOG="$APP_LOG_DIR"/start.log
echo "Start application '$APP_NAME'"
if [ -f $APP_PID ]; then
PID=`cat $APP_PID`
if [ -z $PID ]; then
echo "File '$APP_PID' exist but it's empty, delete it"
rm $APP_PID
elif ! ps h -p $PID > /dev/null; then
echo "File '$APP_PID' exist but process with pid '$PID' doesn't exist, delete it"
rm $APP_PID
else
echo "$APP_NAME already started (file $APP_PID exist)"
exit
fi
fi
mkdir -p $APP_LOG_DIR
if [ $APP_EXPORT_LIB_DIR ]; then export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$APP_EXPORT_LIB_DIR; fi
echo =========================================== >> $MAIN_LOG
date >> $MAIN_LOG
if [ -f $APP_BIN ]; then
./$APP_BIN -l $APP_LOG_DIR -c $APP_CONF -p $APP_PID >> $MAIN_LOG &
else
echo "Error: binary file '$APP_BIN' doesn't exist"
exit 1
fi
if [[ $? != 0 ]]; then
echo "Not started"
else
echo "Started"
fi
Скрипт останова имеет куда более изощренную логику, для медленного останова сервера.
stop.sh
#!/bin/bash
source init.conf
if [ ! -f $APP_PID ]; then
echo "'$APP_NAME' not started (file $APP_PID doesn't exist)"
exit
fi
PID=`cat $APP_PID`
if ! ps h -p $PID > /dev/null
then
echo "'$APP_NAME' not started, removing old $APP_PID file"
rm $APP_PID
exit
fi
if ! kill -s SIGTERM $PID
then
echo "Cannot stop process"
exit
fi
for i in {1..10}
do
if ps h -p $PID > /dev/null
then
echo -n .
sleep 1
else
echo "Stopped"
exit
fi
done
echo
echo "Can't correctly stop application, finish him"
kill -9 $PID
rm $APP_PID
PS. Спасибо моему коллеге Андрею за то, что предложил более юзабельную версию скрипта stop.sh
Package.sh
В каждом из проектов у меня есть скрипт package.sh цель которого, создать достаточный инсталляционный пакет. Как правило это заархивированная папка приложения с набором файлов достаточным для работы приложения. Минимальный набор это скприты запуска останова, конфигурационный файл, само приложение, и папка для логов.
package.sh
#!/bin/bash
APP_NAME=projectnull
VERSION=`./version.sh show`
PACKAGE=$APP_NAME.$VERSION.tar.bz2
echo "Create instalation package of '$APP_NAME' ($PACKAGE)"
TEMP_FOLDER=$APP_NAME
FILES=( "build/release/projectnull"
"start.sh"
"stop.sh"
"init.conf"
"*.conf" )
LOG_DIR=logs
if [ -d $TEMP_FOLDER ]; then
rm -rf $TEMP_FOLDER
fi
mkdir $TEMP_FOLDER
for i in "${FILES[@]}"
do
echo "copy '$i'"
cp $i $TEMP_FOLDER
done
echo creat $LOG_DIR
mkdir $TEMP_FOLDER/$LOG_DIR
tar -cjf $PACKAGE $TEMP_FOLDER
rm -rf $TEMP_FOLDER
echo Finished
Функционал
И так, что же мне обычно нужно, что бы приступить непосредственно к программированию:
- Параметры командной строки первой важности
- Файл конфигурации
- Простой способ взаимодействия с логгером
- Возможность для корректной остановки приложения
Начнем по порядку:
Параметры командной строки первой важности
Я выделил для себя три таких параметра. Сейчас я попробую объяснить, почему именно они.
Директория для логирования. Причина, по которой я не храню этот параметр в конфигурационном файле, это то, что в процессе разбора конфигурационного файла уже могут случиться ошибки, которые я хочу логировать. Почему директория? Я привык, что каждый запуск это отдельный лог файл, таким образом, легче удалять старые логи.
Конфигурационный файл Если не через командную строку, то как? Особенно если у вас несколько конфигураций, которые вы хотите быстро переключать.
PID файл. Единственная причина, почему я не храню его в конфигурационном файле это то, что данный параметр используется сразу в 2 местах. В start и stop скриптах. И гораздо проще вынести его в отдельный файл init, который подключается к start stop скриптам, и править его один раз, чем два (я про conf файл).
Разбор командной строки и файла конфигурации, производится средствами boost::program_options
program_options.cpp
void ProgramOptions::load(int argc, char* argv[])
{
options_description desc("Allowed options");
desc.add_options()
("help,h", "produce help message")
("config,c", value<std::string>(&conf_file)->default_value(std::string(CONF_FILE)), "set configuration file")
("logdir,l", value<std::string>(&log_dir)->default_value(std::string(LOG_DIR)), "set log directory")
("pidfile,p", value<std::string>(&pid_file)->default_value(std::string(PID_FILE)), "set pid file")
;
variables_map vm;
store(parse_command_line(argc, argv, desc), vm);
notify(vm);
if (vm.count("help")) {
std::cout << desc << "\n";
exit(0);
}
std::cout << "Will be used the next options:" << std::endl
<< "CONF_FILE = " << conf_file << std::endl
<< "LOG_DIR = " << log_dir << std::endl
<< "PID_DIR = " << pid_file << std::endl
;
}
Каждый из параметров имеет значения по умолчанию
./projectnull -h
Allowed options:
-h [ --help ] produce help message
-c [ --config ] arg (=project.conf) set configuration file
-l [ --logdir ] arg (=logs) set log directory
-p [ --pidfile ] arg (=project.pid) set pid file
Логирование
Я не стал изобретать свой логгер, как правило, в каждой фирме он свой. В данном проекте я ограничился выводом в консоль, в режимах Note и Error. Единственно требование, которое я предъявляю к логгеру это то, что он должен поддерживать интерфейс подобный printf. Согласитесь со мной ведь printf это прекрасно. Я лишь добавил макросы для удобного процесса логирования.
logger.h
Output:
#define ENTRY __PRETTY_FUNCTION__
#define LOG_0(s) ;
#define LOG_1(s) Log::note(ENTRY, s)
#define LOG_2(s, p1) Log::note(ENTRY, s, p1)
#define LOG_3(s, p1, p2) Log::note(ENTRY, s, p1, p2)
#define LOG_4(s, p1, p2, p3) Log::note(ENTRY, s, p1, p2, p3)
#define LOG_5(s, p1, p2, p3, p4) Log::note(ENTRY, s, p1, p2, p3, p4)
#define LOG_X(x,s,p1,p2,p3,p4,FUNC, ...) FUNC
#define LOG(...) LOG_X(,##__VA_ARGS__,\
LOG_5(__VA_ARGS__),\
LOG_4(__VA_ARGS__),\
LOG_3(__VA_ARGS__),\
LOG_2(__VA_ARGS__),\
LOG_1(__VA_ARGS__),\
LOG_0(__VA_ARGS__)\
)
LOG("Appication started, version: %s (%s)", VERSION, BUILD_TYPE);
Output:
[N][int main(int, char**)]Appication started, version: 1.0.3 (RELEASE)
Останов
На мой взгляд, корректная остановка, это одна из важнейших функций ПО о которой часто забывают. Как правило, сделать корректную остановку в уже разработанном ПО это непосильная задача. Другое дело, если придерживаться определенной стратегии с самого начала, то это становится пустяком. Я не рассматриваю всякие изощренные способы получения команды останова по сети, по SMS или через спутник. Я просто ловлю некоторые сигналы, после чего инициирую процедуру корректного останова.
void Mediator::wait_exit()
{
LOG("Set up waiting exit");
sigset_t set;
int sig;
sigemptyset(&set);
sigaddset(&set, SIGINT);
sigaddset(&set, SIGQUIT);
sigaddset(&set, SIGTERM);
sigaddset(&set, SIGTSTP);
sigprocmask(SIG_BLOCK, &set, NULL);
sigwait(&set, &sig);
switch (sig) {
case SIGINT:
case SIGQUIT:
case SIGTERM:
case SIGTSTP:
LOG("Catched signal to stopping application");
stop();
break;
}
}
Единственное что требуется это вызвать функцию wait_exit() в главном потоке, после выполнения всех активный действий.
LOG("Appication started, version: %s (%s)", VERSION, BUILD_TYPE);
{
Mediator mediator;
mediator.start();
mediator.wait_exit();
}
LOG("Applicatiom stopped");
Спасибо mejedi за указание некорректности использования обработчика сигналов для данных нужд. Надеюсь я правильно истолковал(реализовал) ваше предложение.
Структура приложения
Вот мы и добрались к финальной части. Как уже многим стало ясно, я использую паттерн «Медиатор». Конечно, не во всей его красе, ибо никакой бизнес логики пока нет.
class Mediator: public Thread
{
public:
Mediator();
virtual ~Mediator();
void wait_exit();
private:
virtual void run();
void load_app_configuration();
void create_pid();
private:
Pid pid_;
};
Если какую то работу предполагается выполнять в отдельном потоке, то для такой задачи должен существовать отдельный класс, унаследованный от специального класса Thread.
class Thread
{
public:
void start() {th_ = boost::thread(boost::bind(&Thread::run, this));}
void stop() {th_.interrupt(); th_.join();}
virtual ~Thread(){}
private:
virtual void run() = 0;
private:
boost::thread th_;
};
Цель которого поддержать в едином формате процесс запуска и останова.
Репозиторий
Проект доступен в Google Code, но только для read-only. Это не потому что я жадный, я просто не знаю как открыть доступ для всех. При желании вносить правки, пишите ваш g-email, добавлю вас к проекту.
svn checkout http://project-null.googlecode.com/svn/trunk/ project-null-read-only
Пара слов...
Идея оформить данную наработку в осязаемый шаблон возникла у меня месяца два назад, в процессе очередного проекта который нужно было слобзать быстро и с чистого листа. В ходе написания проекта я пришел к выводу, что это уже не первый раз, когда у меня получается подобная архитектура, и что нет смысла каждый раз вспоминать все подводные камни и приходить к тому же решению, которое использовал раньше, нужно оформить его как шаблон. Я долго мучился на счет целесообразности написания этой статьи, но вспомнив притчу про учителя и стакан воды, я решил, что лучше мне скажут, что статья не стоит и ломаного гроша, чем я буду продолжать думать о ее целесообразности.
Спасибо за внимание.
PS. Добавлены различные проверки PID файла при запуске. Обрабатываются кейсы файл с PID есть — процесса нет, PID файл пустой.
