Как спроектировать конечный автомат для неблокирующего ввода-вывода?

Похоже, вы хотите, чтобы конечный автомат имел очередь событий. Поставьте события в очередь, начните обработку первого, а когда это завершится, извлеките следующее событие из очереди и начните с него. Таким образом, конечный автомат управляется не напрямую клиентским кодом, а очередью.

Это означает, что любая логика, предполагающая использование результата одного перехода в следующем, должна быть в машине. Например, если на странице «вход завершен» указано, куда идти дальше. Если это невозможно, то событие, возможно, может включать обратный вызов, который машина может вызвать, чтобы вернуть все, что ей нужно знать.

Задавая этот вопрос, у меня уже был рабочий дизайн, о котором я не хотел писать, чтобы не искажать ответы в любом направлении :) Я собираюсь описать в этом псевдоответе, какой у меня дизайн.

Помимо конечного автомата у меня есть очередь событий. Вместо того, чтобы отправлять события непосредственно на машину, я помещаю их в очередь. Однако существует проблема с сетевыми событиями, которые являются асинхронными и происходят в любой момент. Если очередь не пуста и приходит сетевое событие, я не могу поместить его в очередь, потому что машина застрянет в ожидании, прежде чем обработать события, уже находящиеся в очереди. И машина будет ждать вечно, потому что это сетевое событие ожидает позади всех событий, помещенных в очередь ранее.
Чтобы решить эту проблему, у меня есть два типа сообщений; обычные и приоритетные. Обычные — это отправленные мной, а приоритетные — все сетевые. Когда я получаю сетевое событие, я не помещаю его в очередь, а вместо этого отправляю прямо на машину. Таким образом, он может завершить свою текущую задачу и перейти к следующему состоянию, прежде чем извлекать следующее событие из очереди событий.
Он работает таким образом только потому, что мои события и сетевые события чередуются ровно 1:1. Из-за этого, когда машина ожидает сетевого события, она ничем не занята (поэтому готова принять его и не пропустить) и наоборот - когда машина ждет мою задачу, она ждет только мою задачу, а не другую сеть одна.

Я задал этот вопрос в надежде на более простой дизайн, чем тот, что у меня есть сейчас.

Строго говоря, нельзя. Поскольку у вас есть только состояние «Подключение», вы не знаете, нужен ли вам верхний вход после этого. Вам нужно будет ввести состояние «ConnectingWithIntentToLogin», чтобы представить результат события «Подключиться, затем войти» из состояния «Пуск».

Естественно, будет много перекрытий между состояниями «Подключение» и «ConnectingWithIntentToLogin». Этого проще всего добиться с помощью архитектуры конечного автомата, которая поддерживает иерархию состояний.

--- редактировать ---

Читая ваши более поздние реакции, теперь ясно, в чем ваша настоящая проблема.

Очевидно, вам нужно дополнительное состояние, вне зависимости от того, встроено ли оно в FSM или вне его в отдельной очереди. Давайте следовать модели, которую вы предпочитаете, с дополнительными событиями в очереди. Суть здесь в том, что вам интересно, как «перемежать» эти события в очереди с событиями в реальном времени. Вы этого не сделаете — события из очереди активно извлекаются при входе в определенные состояния. В вашем случае это будут состояния «* ed», такие как «Подключено». Только когда очередь пуста, вы останетесь в состоянии «Подключено».

Если вы не хотите блокировать, это означает, что вам не нужны ответы в сети. Если, с другой стороны, ответы вас интересуют, вы должны заблокировать ожидание их. Попытка спроектировать свой FSM иначе быстро приведет к тому, что размер вашего автомата достигнет бесконечности.

Как насчет перемещения конечного автомата в другой поток, т.е. е. QThread. Я бы внедрил входную очередь в конечный автомат, чтобы я мог отправлять запросы без блокировки, и выходную очередь для чтения результатов запросов. Вы даже можете вызвать выделенную функцию в своем основном потоке через connect(...), если будет получен результат запроса, в этом отношении Qt является потокобезопасным.

Таким образом, ваша конечная машина может блокироваться столько времени, сколько потребуется, не блокируя вашу основную программу.

Похоже, вы просто хотите составить список блокирующих операций ввода-вывода в фоновом режиме.

Итак, выполните поток:

while( !commands.empty() )
{
  command = command.pop_back();
  switch( command )
  {
  Connect: 
    DoBlockingConnect();
    break;
  ...
  }
}
NotifySenderDone();