Qraizer: Вопрос как раз в этом самом трансляторе. В идле он просто ожидает какого-либо события. Это может быть:

• входящий запрос от виртуального тестера из нашей сети;
• входящий запрос от стенда из своей сети;
• консольный запрос от оператора тестового окружения.

Ну да, простая консолька у него тоже есть, надо ж как-то отлаживать тесты и просто изучать поведение железки. Как-никак в ней 20 процессоров и у всех свои законы поведения. Одной только математики в PDF на три мега, и это не считая всей железно-протокольной обвязки. Из-за асинхронности всех событий он обвешан нитками, которые к тому же ещё и взаимодействуют друг с другом: консоль с UDP, UDP с консолью, TCP с UDP, UDP с TCP, консоль с ТCP и UDP. Нужно уметь опрашивать сокеты и очередь событий. Нужно отвечать на события с сохранением инвариантов протокола, чтоб не путать, кому что. И это непросто, учитывая общую асинхронность системы стенд/тестер. Нужно элементарно уметь завершать работу по запросу и уметь реагировать на сетевые сбои. Код новый? Новый. Применим std? Почему бы и нет. Да и внезапный ( :D ) перекос политик кампаний в сторону открытых архитектур никто не отменял. Применил.
Сокеты умеют таймауты только на select(), а без таймаутов беда, ибо пока, скажем, виртуальный тестер не отзовётся, обслужить запрос от UDP-нитки будет невозможно. Есть условные переменные, которым в довесок подавай мютексы и лямбды, да ещё и соизволь сам нотифить ими в нужные моменты. Хочешь завершить работу, дождись джойнов от всех ниток, иначе хрен тебе в журналах аудита от эксепшнов. В итоге код управления потоками представляет собой жуткий винегрет. На каждую переменную по мьютексу и паре лямбд опроса и установки. Всё это надо захватывать из контекста или передавать параметрами, иначе оно должно валяться прямо в глобальном скопе и закардорджено. И не забывать после смены состояния переменой нотифи кидать, за тебя тебе этого никто не напомнит. Рабочий цикл каждой нитки состоит из отдельных опросов "своего" сокета и каждой из переменных с конкретными лямбдами. При ошибках эксептишь себе в catch, чтобы корректно завершиться, где опять же не забудь изменить состояние и отнотифицироваться, а если таковое случится во время обслуживания запроса от другой нитки, а не стенда или виртуального тестера, то там тоже нужно предусмотреть код корректной реакции на сие.
Все эти активити вполне формальны и моим вторым желанием (после первого – забить) было оформить всё красиво. В кулуарах я сделал класс над переменными и все кишки упрятал туда. Стало лучше, если не глядеть во внутрь класса. Чего не удалось, так это упрятать формализм опроса/установки/сброса, там что от лямбд избавиться не получилось, но стало хотя бы приемлемо пользовать. И тут вдруг меня осенило полиморфизмом. На скорую руку я сварганил стратегии а-ля Александреску, и внезапно на этом метаклассе я понял, что условных переменных снаружи не осталось. Так я лишний раз убедился, что условные переменные в этой задаче в общем-то и не нужны, а их наличие является лишь следствием того, что std непродуман и слишком сырой. Ибо всё вот это вот, если делать по-хорошему, а не с кишками наружу, всё равно придётся делать из раза в раз по одной и той же схеме.
Единственное, чего ещё не хватало для полного счастья, это возможности создавать композиции таких объектов. Мне оно было не надо, но за пару перекуров я набросал в голове, как бы это сделал. И вот совсем уж внезапно вдруг неожиданно для себя прям вот снег на голову (шутки шутками, но реально, я чуть не поперхнулся дымом, когда осознал) у меня получилось ...WinAPI. Не, конечно реализовано там всё по-другому, но внешне архитектура точь в точь. Морали не будет. Пусть каждый делает выводы сам. Я свои озвучил выше.

https://forum.sources.ru/index.php?showtopic=421430&view=findpost&p=3847309