Однопоточный сервер

[halcyon]

Здравствуйте. Допустим, имеется:

//...
unsigned int sockets[16];
int index = 0;
struct timeval tm;
fd_set input;
while(result != INVALID_RESULT)
{
     FD_ZERO(&input);
     FD_SET(server_socket, &input);
     tm.tv_sec = delay; // delay = [0...n ];
     tm.tv_usec = 0;

     result = select(server_socket+1, &input, NULL, NULL, &tm)
     switch(result)
     {
         case -1: // ...
         case 0 : // ...

         default: {
            if(IsExistNewConnection() == true)
            sockets[index++] = accept(server_socket, NULL, NULL);
            //...
            /* Здесь выполняется все необходимое по приему сообщений
             от подключенных сокетов в sockets[16], отключение клиентов 
             и подключение новых. Все работает отлично.
            */
     }
}

Сервер должен рассылать клиентам(sockets[16]) сообщения, но методы fgets(); и cin.getline(); прерывают выполнение потока, и поэтому прием сообщений от клиентов будет прерван операцией ввода на сервере. Пришлось сделать операцию ввода в отдельном потоке, куда передается в качестве параметра массив sockets[16], и этим сокетам отправляются введенные сообщения.
Вопрос: возможно ли организовать ввод и отправку сообщений в том же потоке, где производится прием сообщений от клиентов?

[Nuklon]

возможно, ведь у тебя таймер весит на select, только учти, что голод не тётка.

[halcyon]

к сожалению, не совсем понял вашу мысль

[Кащей]

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

[_Bers]

Сообщение от halcyon

Вопрос: возможно ли организовать ввод и отправку сообщений в том же потоке, где производится прием сообщений от клиентов?

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

Тогда возникнет иллюзия, что все задачи выполняются параллельно.

Например, ввод на сервере разбивается на подзадачки:

Начало: Вечный цикл главного потока:

Подзадачка 1. была ли нажата клавиша? Да - поместить в буффер вводимых данных ещё один символ.
Нет - ничего не делаем. Выходим из процедуры.

Подзадачка 2. В буффере входных данных присутствует код клавиши ентер? Да - включаем флаг о завершении ввода.
Нет - ничего не делаем.

Подзадачка 3. Флаг о завершении ввода включен? Да - сбрасываем этот флаг, и что-то делаем с полученными данными.
Нет - ничего не делаем.

Подзадачка 4. Любые другие действия.

Конец: Повторить вечный цикл главного потока.

Вместо одной залипающей функции ввода получаем три коротеньких, простеньких и изолированных друг от дружки. Которые не залипают.

Их можно вызывать в любом порядке следования.
Допустим, можно сначала вызвать задачку 3, потом задачку 2, потом задачку 1. От этого бизнес-логика работы ввода никак не изменится.

Этот фактор позволяет легко контролировать сложность происходящего.
И будет работать прекрасно до тех пор, пока не нарушится инкапсуляция задач.

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

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

Если же вынести в отдельный поток ввод, только потому, что он "залипает" - это на ровном месте просаживать производительность, и усложнять проект.

Ради только этого я бы не стал использовать многопоточность.

[halcyon]

_Bers, спасибо за содержательный и развернутый ответ, он оказался полезным. Плюсую.