Суть проблемы в следующем. Есть программулина, которая обильно напичкана потоками и, как следствие, мьютексами и переменными условия. У программулины имеется две версии. Одна создаёт демона и свободно праит выполняя поставленную задачу, а вторая не демонизируется, но выполняет те же действия, при этом отчитываясь за каждый шаг в лог файле. Так вот, вторая версия работает нормально, а с первой вылез совершенно не подвластный моему разумению баг (или это фича?..). Прога спокойно создаёт демона и сворачивает удочки, а вот в демоне первый же вызов pthread_cond_signal вываливает программу в корку (?!)... Ну, не хочет сигналить и всё тут. Самое дебильное в этом то, что обе версии отлично работают под федорой (первой пока), а вот под фрёй только вторая, хотя код одинаков до последнего знака табуляции, просто в первой есть fork (и всё, что потом полагается), а во второй нет... Вчём дело? Помогите, плиз...
>Суть проблемы в следующем. Есть программулина, которая обильно напичкана потоками и, как
>следствие, мьютексами и переменными условия. У программулины имеется две версии. Одна
>создаёт демона и свободно праит выполняя поставленную задачу, а вторая не
>демонизируется, но выполняет те же действия, при этом отчитываясь за каждый
>шаг в лог файле. Так вот, вторая версия работает нормально, а
>с первой вылез совершенно не подвластный моему разумению баг (или это
>фича?..). Прога спокойно создаёт демона и сворачивает удочки, а вот в
>демоне первый же вызов pthread_cond_signal вываливает программу в корку (?!)... Ну,
>не хочет сигналить и всё тут. Самое дебильное в этом то,
>что обе версии отлично работают под федорой (первой пока), а вот
>под фрёй только вторая, хотя код одинаков до последнего знака табуляции,
>просто в первой есть fork (и всё, что потом полагается), а
>во второй нет... Вчём дело? Помогите, плиз...pthread + fork всегда имели проблемы и достаточное количество unspecified behavior. смотрите в POSIX.
// wbr
>pthread + fork всегда имели проблемы и достаточное количество
>unspecified behavior. смотрите в POSIX.Святые слова. IMHO, единственный безопасный вариант - сначала делать
все нужные fork()и, а уже затем баловаться с потоками. Единственно
когда точно не вылезет проблем с fork()ом pthread-овой программы -
это ежели сразу за fork()ом exec*() идёт :)
>Святые слова. IMHO, единственный безопасный вариант - сначала делать
>все нужные fork()и, а уже затем баловаться с потоками. Единственно
>когда точно не вылезет проблем с fork()ом pthread-овой программы -
>это ежели сразу за fork()ом exec*() идёт :)Это что ли демоном другую программу запускать... спасибо... попробую... если не прокатит моя новая версия (додумался, как без переменных условия (и, соответственно, без вызова pthread_cond_signal) обойтись. невдалей, конечно, но что делать... :-( )
>>Святые слова. IMHO, единственный безопасный вариант - сначала делать
>>все нужные fork()и, а уже затем баловаться с потоками. Единственно
>>когда точно не вылезет проблем с fork()ом pthread-овой программы -
>>это ежели сразу за fork()ом exec*() идёт :)
>
>Это что ли демоном другую программу запускать... спасибо... попробую... если не прокатит
>моя новая версия (додумался, как без переменных условия (и, соответственно, без
>вызова pthread_cond_signal) обойтись. невдалей, конечно, но что делать... :-( )аналогичная проблема недавно обсуждалась в почтовых рассылках на NetBSD. userland pthread + fork(). симптомы аналогичны. вывод был простой - если вам актуальна надежность кода, не используйте потоки и процессы в одном приложении. понятно, что такое поведение implementation dependant. однако, даже в QNX6, где поддержка pthread таки на высоте, смешивание потоков и процессов может привести к самым забавным результатам.
// wbr
>аналогичная проблема недавно обсуждалась в почтовых рассылках на NetBSD. userland pthread +
>fork(). симптомы аналогичны. вывод был простой - если вам актуальна надежность
>кода, не используйте потоки и процессы в одном приложении. понятно, что
>такое поведение implementation dependant. однако, даже в QNX6, где поддержка pthread
>таки на высоте, смешивание потоков и процессов может привести к самым
>забавным результатам.
>
>// wbrСпасибо за сочувствие... ;Ь
Как я понял из всего выше сказанного, нужно забыть про fork и просто, отключая программулину от всех потоков ввода-вывода, запускать программу с nohup...