POSIX: как так можно работать

Особенно хочется иметь одновременно ualarm и nanosleep.

> Вот из man-a для ualarm:

Ты не на то внимание обращаешь. ВотЪ: "This function is obsolete. Use setitimer(2) or POSIX interval timers (timer_create(3), etc.) instead."

Наверное, ualarm мог реализовываться на setitimer, timer_* или прочих, поэтому unspecified.

> То-есть они все несовместимы между собой.

А это ты откуда взял? У меня маны на setitimer и timer_create ничего такого не говорят.

> Где можно почитать как это все правильно использовать?

ХЗ. Надо использовать что-нибудь одно, и это одно - timer_* :) Всё остальное - исторический багаж.

> ХЗ. Надо использовать что-нибудь одно, и это одно - timer_* :) Всё остальное - исторический багаж.

Хорошо, но если мне нужно сделать задержку на 1 секунду скажем, мне что городить огород из таймеров?

> но если мне нужно сделать задержку на 1 секунду скажем, мне что городить огород из таймеров?

Если это единственное, что тебе нужно, используй sleep :) timer_* - это для более сложных случаев, когда нужно отслеживать тайм-ауты и т.д.

> Если это единственное, что тебе нужно, используй sleep :) timer_* - это для более сложных случаев, когда нужно отслеживать тайм-ауты и т.д.

Нужно одновременно 3 вещи:

1. Периодически тикающий таймер.
2. Возможность в произвольных местах делать задержку от сотен мкс до десятков секунд.
3. Посылать/обрабатывать сигналы.

1+3  - не проблема, но второе при этом становится очень загадочным.

> второе при этом становится очень загадочным.

Тебе ж через 5 минут будет стыдно, что ты это написал :)

Предлогается по таймеру увеличивать счетчик, а дадержку делать на базе этого счетчика? Или я что-то упускаю?

> Предлогается по таймеру увеличивать счетчик, а дадержку делать на базе этого счетчика?

Ну можно и так, но зачем? Сделай функцию deepsleep: в начале получаешь текущее время, вызываешь nanosleep, если она вернула EINTR - вычисляешь оставшееся время и ждешь его.

Я так и сделал, просто видимо не правильно восприянл вот это:

> ХЗ. Надо использовать что-нибудь одно, и это одно - timer_* :) Всё остальное - исторический багаж.

Если использовать nanosleep() - это нормально, то все OK.

А вообще чего-то действительно бардака много.

И еще по-ходу дела вопрос:

Для функций принимающих указатели на структуры можно-ли как-то узнать, нужно сохранять содержимое этой структуры после вызова функции или нет?

Например sigevent для timer_create(). Из man-a этого непонятно.

timer_* может генерить не SIGALRM, а указанный сигнал. Тогда таймер своим тиканием не будет смущать других, кто использует этот же сигнал. Чтобы сигналы от таймера не прерывали nanosleep или ещё кого, надо поставить флажок SA_RESTART в sigaction.

С таймером можно ещё так работать: заблокировать SIGALRM, соорудить таймер и запустить цикл с sigwait.

Все функции, кроме timer_* и nanosleep - по сути устаревшие, на них можно забить. Только не все оси умеют таймеры :/

> Для функций принимающих указатели на структуры можно-ли как-то узнать, нужно сохранять содержимое этой структуры после вызова функции или нет?

Не нужно.

Я сделал таймер с sigev_notify = SIGEV_THREAD; и теперь все хорошо - он при срабатывпнии просто вызывает функцию.

> sigev_notify = SIGEV_THREAD; и теперь все хорошо

> он при срабатывпнии просто вызывает функцию.

O_o

Что-то не так?

ЕМНИП, SIGEV_THREAD создает нить для обработки сигнала. Каждый раз.

Сильно по ресурсам затратно? Ok, верну сигналы :)

> Сильно по ресурсам затратно?

Понятия не имею. Тебе судить :)

> Ok, верну сигналы :)

у sigev_notify могут быть и другие значения.

>> Ok, верну сигналы :)

> у sigev_notify могут быть и другие значения.

Линукс других вроде бы не умеет. Кстати, SIGEV_THREAD эмулируется через сигналы глибцем: создаётся спецпоток, который ловит сигналы от таймера и создаёт новые потоки. Короче, производительность в заду... Можно юзать, если как раз и требуется потоки создавать по таймеру или делать ещё что-нибудь тяжёлое.

> Линукс других вроде бы не умеет

По-моему, он только SIGEV_THREAD и не умеет :) Остальные варианты проще.

В ядре есть вот такие дефайны:
#define SIGEV_SIGNAL    0       /* notify via signal */
#define SIGEV_NONE      1       /* other notification: meaningless */
#define SIGEV_THREAD    2       /* deliver via thread creation */
#define SIGEV_THREAD_ID 4       /* deliver to thread */

Причем последнее - нестандартное расширение созданое как раз в помощь libc и не для пользователя особо не предназначено.

доставка signal notification - это _всегда_ сигнал. Он может отправляться в указанную нить, или в дефолтную (вот только не помню, как она выбирается в многонитвеом процессе). SIGEV_THREAD в Линуксе - это создание нити + SIGEV_THREAD_ID, насколько я понимаю.