Здравствуйте, Areg, Вы писали:
A>нужно написать маленькую программу которая бы асинхронно запускала некоторое количество программ, следила бы за их окончанием и производила некоторые действия. Как наиболее эффективно это сделать? Через обработчик SIGCHLD?
Ага.
... << RSDN@Home 1.1.3 beta 2 >>
Здравствуйте, Areg, Вы писали:
A>Здравствуйте, m.a.g., Вы писали:
MAG>>Ага.
A>Вопрос возникает.
A>В обработчике SIGCHLD (SIGCLD) можно ли использовать мьютексы? Я хочу в обработчике стереть задачу из списка активных задач — сначала делаю lock, стираю задачу, потом unlock. Может ли в такой схеме сигнал пропасть?
Мутексы сигналам перпендикулярны. Чтобы сигнал не пропадал, играйся с sigaction и иже с ним по поводу reliable signals.
... << RSDN@Home 1.1.3 beta 2 >>
Здравствуйте, Areg, Вы писали:
A>Здравствуйте, m.a.g., Вы писали:
MAG>>Ага.
A>Вопрос возникает.
A>В обработчике SIGCHLD (SIGCLD) можно ли использовать мьютексы? Я хочу в обработчике стереть задачу из списка активных задач — сначала делаю lock, стираю задачу, потом unlock. Может ли в такой схеме сигнал пропасть?
А что, программа многопоточная?
А вообще, в обработчике сигнала слишком много делать нежелательно (просто трудно реализовывать, т.к. много чего нельзя) — сигналы в UNIX асинхронные.
Например, сигнал может случиться, когда твоя программа вызвала malloc, поэтому из обработчика сигнала нельзя вызывать malloc
А поэтому, нельзя вызывать printf
Т.е. очень много чего нельзя.
Думаю, не стоит в обработчике сигнала пытаться лочить mutex — возможно придётся долго ждать.
Обычно в обработчике поднимают какой-нибудь флажок, что надо что-то обработать, а обрабатывают уже потом, после завершения обработчика.
Не бойся пропустить SIGCHLD — у тебя есть список дочерних процессов и можно лишний раз сделать wait() или waitpid() и они тебе расскажут, кто завершился, пока ты был занят и мог пропустить SIGCHLD.
