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

мне показалось, или вы создавая тред предложили остальным стать юзерами ? :-)

Показалось.

тогда вместо тренировки в механизмах логичнее предлагать выбор источника времени

Как я уже говорил, если кому-то будет нужно, можно будет на эту тему подумать в будущей версии.

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

Цель не в этом. Одна нить должна обрабатывать 100500 таймеров.

Ваш list_timer_t просто таки напрашивается (иначе какой в нём смысл) на неблокирующую реализацию.

Ахринеть, дайте два. Давайте еще и lock-free list подтянем и механизм hazard pointers в придачу.

Впрочем, если 8-10M таймеров в секунду не будет хватать, придется и об этом думать.

зачем пользователю выбирать некий «таймерный механизм» ?? я вот вижу только одну причину - автору лень делать хорошо :(

Если вы не видите, то это могут быть ваши личные проблемы. Как с уровнем квалификации, так и с элементарным кругозором.

Тут уже, если не ошибаюсь, несколько раз говорилось, что на реально больших объемах таймеров нет общего универсального механизма. В каждом есть свои плюсы и минусы. Соответственно, если задача реально требовательная к реализации таймеров, то пользователю придется вникать, что лежит под капотом. И «сделать хорошо» будет означать предложить несколько реализаций под разные сценарии. Поинтересуйтесь, на досуге, сколько типов таймерных очередей поддерживает тот же ACE Framework. И причинами, побудившими авторов ACE к разработке такого количества реализаций.

Если задача не требовательная, то timer_heap или timer_wheel, в зависимости от приблизительного количества таймеров.

что-то фантазии не хватает, чтобы представить это IRL

А физдеть не по теме хватает? Попробуйте думать, прежде чем какашки для разбрасывания в руки брать.

Сценарий, с которым я сам сталкивался, это рестрансляция прикладных сообщений. Некий промежуточный компонент B получает сообщения от A, передает их C, выставляя тайм-аут на получение ответа от C. Если в течении тайм-аута ответ не получен, то В отсылает A соответствующее уведомление и забывает про это сообщение. Получается исключительно монотонный таймер, все тайм-ауты одинаковые, никаких периодических заявок. Идеальный сценарий для timer_list.

шедеврально - это в шаблонах С++ ТРИ полных реализации xxx_timer отличающихся внутренним типом prio.q.

А то, что внутри STL, к примеру, ЧЕТЫРЕ полных реализации простого линейного контейнера объектов (vector, deque, list, forward_list) вас не смущает?

Сейчас три xxx_timer. Возможно, со временем будет больше. Возможно, тогда будет больше информации, которая позволит переиспользовать общие куски кода. Пока удалось переиспользовать только функциональность, вынесенную в thread_basic_t. Еще куда-то напрашиваются enum timer_status_t и ensure_timer_deactivated. Но в том же timer_heap нет timer_status_t и ensure_timer_deactivated там реализуется совсем иначе.

мне показалось, или вы создавая тред предложили остальным стать юзерами ? :-)

Показалось.

тогда вместо тренировки в механизмах логичнее предлагать выбор источника времени

Как я уже говорил, если кому-то будет нужно, можно будет на эту тему подумать в будущей версии.

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

Цель не в этом. Одна нить должна обрабатывать 100500 таймеров.

Ваш list_timer_t просто таки напрашивается (иначе какой в нём смысл) на неблокирующую реализацию.

Ахринеть, дайте два. Давайте еще и lock-free list подтянем и механизм hazard pointers в придачу.

Впрочем, если 8-10M таймеров в секунду не будет хватать, придется и об этом думать.

зачем пользователю выбирать некий «таймерный механизм» ?? я вот вижу только одну причину - автору лень делать хорошо :(

Если вы не видите, то это могут быть ваши личные проблемы. Как с уровнем квалификации, так и с элементарным кругозором.

Тут уже, если не ошибаюсь, несколько раз говорилось, что на реально больших объемах таймеров нет общего универсального механизма. В каждом есть свои плюсы и минусы. Соответственно, если задача реально требовательная к реализации таймеров, то пользователю придется вникать, что лежит под капотом. И «сделать хорошо» будет означать предложить несколько реализаций под разные сценарии. Поинтересуйтесь, на досуге, сколько типов таймерных очередей поддерживает тот же ACE Framework. И причинами, побудивших авторов ACE к разработке такого количества реализаций.

Если задача не требовательная, то timer_heap или timer_wheel, в зависимости от приблизительного количества таймеров.

что-то фантазии не хватает, чтобы представить это IRL

А физдеть не по теме хватает? Попробуйте думать, прежде чем какашки для разбрасывания в руки брать.

Сценарий, с которым я сам сталкивался, это рестрансляция прикладных сообщений. Некий промежуточный компонент B получает сообщения от A, передает их C, выставляя тайм-аут на получение ответа от C. Если в течении тайм-аута ответ не получен, то В отсылает A соответствующее уведомление и забывает про это сообщение. Получается исключительно монотонный таймер, все тайм-ауты одинаковые, никаких периодических заявок. Идеальный сценарий для timer_list.

шедеврально - это в шаблонах С++ ТРИ полных реализации xxx_timer отличающихся внутренним типом prio.q.

А то, что внутри STL, к примеру, ЧЕТЫРЕ полных реализации простого линейного контейнера объектов (vector, deque, list, forward_list) вас не смущает?

Сейчас три xxx_timer. Возможно, со временем будет больше. Возможно, тогда будет больше информации, которая позволит переиспользовать общие куски кода. Пока удалось переиспользовать только функциональность, вынесенную в thread_basic_t. Еще куда-то напрашиваются enum timer_status_t и ensure_timer_deactivated. Но в том же timer_heap нет timer_status_t и ensure_timer_deactivated там реализуется совсем иначе.