История изменений

Она и в вашем случае кончится. Если не раньше.

Да, кончится, и да раньше, в тот момент, когда будет нагрузочное тестирование. Почешут репу, докупят памяти или разнесут обработки запросов на несколько параллельных серверов. Но не будет ситуации, когда рассчитывая на обработку N запросов в секунду, протестировали для верности на 2N и всё работало, а потом, в процессе эксплуатации, всё упало даже на N/4 и только от того, что удалённый чужой сервер вдруг стал медленнее отвечать.

Если задержка не одинакова, то он не эффективен, но работает. И, как по мне, это лучше, чем получать отлуп в рантайме.

Не, практически работать не будет. Представляем ситуацию: 90% таймеров устанавливаются на T и 10% на T/2. При этом реальный запрос отрабатывается в среднем за T/10. И очередь разрослась до пары тысяч. Это будет означать, что в голове очереди будут стоять пара таймеров реально подвисших запросов, потом куча ещё неотменённых T/2 таймеров, потом куча T-таймеров. Это значит при каждой 10м запросе, если реализовывать совсем тупо, то будет проход с конца примерно половины списка. И даже никак не сократить, не выбрать правильный конец для вставки T/2. Так себе решение для хай лоад.

В общем надо по отдельной очереди для каждого значания таймаута вводить, в нашем случае 1 очередь для T и одна для T/2. Ну и как-то внушение проводить, чтоб сильно большое разнообразие таймаутов не использовали.

Она и в вашем случае кончится. Если не раньше.

Да, кончится, и да раньше, в тот момент, когда будет нагрузочное тестирование. Почешут репу, докупят памяти или разнесут обработки запросов на несколько параллельных серверов. Но не будет ситуации, когда рассчитывая на обработку N запросов в секунду, протестировали для верности на 2N и всё работало, а потом, в процессе эксплуатации, всё упало даже на N/4 и только от того, что удалённый чужой сервер вдруг стал медленнее отвечать.