select на сокете, получение «протухших» данных

Ничего не понятно.

select сработает если есть невычитанные данные. Если в системный буфер пришло 20 байт, ты вычитал 10 и не стал читать дальше, то следующий select сработает сразу, и recv вернет еще 10 байт.

вы теоретик ? практик набросает тесты, проверит, разберется.

Связывайте процессы не «через сокет», а через пару сокетов, соединённых друг с другом для передачи данных.

Кажется, вы с ТСом путаете сокеты и пайпы.

Не исключено. Возможно, что и вы их путаете. Это не страшно, - материя-то тонкая.

Данные не пишутся в сокет, данные пишутся через сокет в принимающий процесс. Когда один пишет, его блокирует пока на второй стороне не прочитают.

Селект ничего не пишет и ничего не читает. Он лишь говорит есть ли заблокированный на записи процесс на другом конце.

У epoll кстати есть разные режимы примерно камательно того что ты спрашиваешь. Почитай мануалы по епол для разнообразия.

Для SOCK_STREAM очерёдность гарантируется. На то он и stream. Для SOCK_DGRAM — нет.

В итоге получилось следующее решение.

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

 while (tv.tv_sec != 0) {
 
 rc = select (socketd + 1, &readfds, NULL, NULL, &tv);
 //читаем данные из сокета и проверям на "свежесть"
//если данные старые, то опять попадаем на селект уже с меньшим значением таймаута
}

про epoll - прочитаю, кажется он таки может делать тоже самое своими способами

Как то мутно написано задача... Если сокет один то не вижу ничего криминального в том чтобы его вынести в отдельный поток и оставить блокированным