Следующее (небольшая программа на C и вызывающий ее скрипт на python) ведут себя по-разному в разных Unixes.
В некоторых из них (например, в стабильной версии Debian) приложение C получает сигнал, сообщение печатается нормально из обработчика сигнала и сценарий завершается.В других (например, двухлетняя Ubuntu и OpenBSD) сигнал теряется, и поэтому сообщение вообще не печатается, а сценарий ждет вечно ...
Сигнал доставляется ВСЕГДА, еслив скрипте Python я изменяю это ...
mysub=subprocess.Popen("./cryInAbort", shell=True)
на это ...
mysub=subprocess.Popen("./cryInAbort", shell=False)
Так что получается, что в некоторых Unix-системах промежуточная оболочка "съедает" SIGINT,в то время как в других он перенаправляет его в дочерний процесс (программу на C).
Я позаботился о том, чтобы вызывать только входящие функции в обработчике сигналов, так что это, похоже, не связано с моим кодом C -похоже, что поведение обработки сигналов в "/ bin / sh" (оболочке по умолчанию, используемой Python для порождения вещей) не является "стабильным" в Unixes ...
Я что-то не так делаю?
РЕДАКТИРОВАТЬ: В случае, если вам интересно, почему я использовал «shell = True»: это потому, что в моем реальном коде я не просто передаю «./executable» - я использую код оболочки для циклови подстановочные знаки.
Это код C, который печатается и умирает, когдаон получает SIGINT:
#include <signal.h>
#include <unistd.h>
void my_handler()
{
static const char msg[] = "Goodbye - test was OK.\n";
write(1,msg,sizeof(msg));
fsync(1);
_exit (0);
}
int main()
{
(void) signal (SIGINT, my_handler);
while (1);
}
И это скрипт Python, который проверяет его, отправляя SIGINT:
#!/usr/bin/env python
import subprocess,signal,time
mysub=subprocess.Popen("./cryInAbort", shell=True)
time.sleep(2)
mysub.send_signal(signal.SIGINT)
mysub.wait()