select sleep delay

Надо сорцы смотреть, но чисто идеологически - sleep (особенно nanosleep) должен быть менее затратен. Т.к. select создаёт запись где то в таблицах ядра, которую в течении таймаута планировщик может проверять на наличие i/o, а sleep есть инструкция не переключать контекст на вызвавший его поток до истечения таймаута.

Т.е. с точки зрения «отзывчивости» спать лучше на селекте, а вот с точки зрения производительности всей системы спать лучше с помощью *sleep.

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

ага из твоего слипа с EINTR также спокойно можно выйти.

по сабжу, тем не менее nanosleep() лучше. select() больше в режиме ядра кода исполняет. но это ты даже на rpi2 особо не заметишь.

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

В случае штатного выполнения RR планировщик забудет об этом потоке минимум на таймаут + квант, тут в принципе даже без проверки как оно на самом деле написано сложно придумать какую то ещё ракетную науку. Вот чем тут FIFO будет отличаться с rt приоритетом и выделенным ядром под спящий поток возможно даже интересно.

В чём действительно с тобой согласен - автор не заметит этой разницы в производительности не на встраиваемых делах раз задаёт такие вопросы:)

В случае штатного выполнения RR планировщик забудет об этом потоке минимум на таймаут + квант, тут в принципе даже без проверки как оно на самом деле написано сложно придумать какую то ещё ракетную науку. Вот чем тут FIFO будет отличаться с rt приоритетом и выделенным ядром под спящий поток возможно даже интересно.

там ничего интерестного. когда ты перейдешь в режим ядра по select() там тупо больше кода будет выполняться - вся разница по сути, настолько смешная, что ее на rpi2 или даже rpi1 не увидишь.

Ну, по идее, «rt» планировщик как бэ должен постараться в таких условиях выдать относительно точный отсчёт таймаута, т.к. тут списать на преключения контекста не выйдет. Но это всё домыслы, было бы на самом деле интересно, я бы глянул, а так «интересно на столько, что бы кто-то принёс инфо в прожёванном виде».

Ну, по идее, «rt» планировщик как бэ должен постараться в таких условиях выдать относительно точный отсчёт таймаута, т.к. тут списать на преключения контекста не выйдет. Но это всё домыслы, было бы на самом деле интересно, я бы глянул, а так «интересно на столько, что бы кто-то принёс инфо в прожёванном виде».

мне лень сейчас смотреть как это в лялихе кокретно сделано, пиво пью... сорри.

тут не домыслы, правда больше кода занимает, вопросы

1. на сколько

2. не сделано ли уже оптимизаций на этот счет