Всем здравствуйте. Я расскажу о различных, подчас интересных, эффектах, которые возникают при работе с POSIX сигналами в Windows. Затаривайтесь Вискасом и вперёд.

Конечно же не могу не упомянуть гибкость механизма сигналов POSIX. Этот механизм реализует подобие парадигмы событийного программирования в C#, чем он, собственно, и интересен. Обычно, в коде, написанном на C/C++ мы вызываем функции ядра, например внутри getch(). А вот когда ядро вызывает нас, происходят всякие интересные эффекты: такие как асинхронные вызовы и произвольная логика программы, изменение способа обработки исключительных ситуаций. Чем то напоминает callback.

Здесь мы можем отреагировать на действия пользователя, сигналы от ОС или исключительную ситуацию, возникшую в программе. Программирование происходит прозрачно, т.е. мы можем, например, написать обработчик SIGABRT и красиво изменить способ обработки неперехваченных исключений без исследования исходного кода всей программы, т.к. писать обработчики и генерировать в них специально этот сигнал не нужно, он генерируется сам. Но такая гибкость обусловлена тем, что есть некоторые, не совсем очевидные, аспекты.

Я продемонстрирую несколько экспериментов с сигналами, в которых обнаруживаются не совсем очевидные вещи. В качестве примеров я выбрал обработчики сигналов SIGINT и SIGABRT. Обработчик SIGINT вызывается асинхронно, в ответ на нажатие клавиш CTRL+C. Обработчик SIGABRT вызывается в ответ на необработанную исключительную ситуацию, но не всегда. Я объясню особенности, возникающие в зависимости от способа генерации сигналов и наличия отладчика. Обратите внимание на то, что все эксперименты проводились в Windows, а исходный код компилируется как код C++.

Содержание

1. Обработчики сигналов запускаются в разном контексте в зависимости от того, каким образом сгенерирован сигнал.

2. Обработка исключения, в зависимости от контекста обработчика сигнала.

3. Обработчик сигнала SIGABRT вызывается, если программа выполняется не под отладчиком.

Исходный код программы

#include <windows.h>

#include <stdlib.h>
#include <stdio.h>
#include <conio.h>

#include <signal.h>
#include <errno.h>

#define SIGINT_RAISE

int _get_thread_id()
{
	HANDLE hThread = 0;
	DWORD dwId = 0;
	hThread = GetCurrentThread();
	dwId = GetThreadId(hThread);
	return (int)dwId;
}

void funcabrt(int sig)
// обработчик неперехваченного исключения
{
	_set_abort_behavior(0, _CALL_REPORTFAULT);
	perror("funcabrt");
	printf("Thread ID: %d\n", _get_thread_id());
	_getch();
};

void funcint(int sig)
// обработчик нажатия клавиш CTRL+C
{
	try
	{
		printf("funcint\n");
		printf("Thread ID: %d\n", _get_thread_id());
		_getch();
		throw (int)ERANGE;
	}
	catch (int err)
	{
		_set_errno(err);
		throw;
	}
	
};

int main()
{
#if defined(SIGINT_RAISE)
	printf("Raise SIGINT mode on\n");
#else
	printf("Raise SIGINT mode off\n");
#endif 
	printf("main\n");
	printf("Thread ID: %d\n", _get_thread_id());
	try
	{
		if (signal(SIGABRT, funcabrt) == SIG_ERR) exit(EXIT_FAILURE);
		if (signal(SIGINT, funcint) == SIG_ERR) exit(EXIT_FAILURE);
#if defined(SIGINT_RAISE)
		raise(SIGINT);
#endif 
		while (1); // нажмите CTRL+C вылетит птенец
	}
	catch (int err)
	{
		printf("catch\n");
		_getch();
	};
};

Обработчики сигналов запускаются в разном контексте в зависимости от того, каким образом сгенерирован сигнал.

void funcint(int sig)
// обработчик нажатия клавиш CTRL+C
{
    try
    {
        printf("funcint\n");
        printf("Thread ID: %d\n", _get_thread_id());
        _getch();
        throw (int)ERANGE;
    }
    catch (int err)
    {
        _set_errno(err);
        throw;
    }
    
};

Случай, когда сигнал возбужден программой Обработчик запускается в контексте нашей программы.

Вывод

Raise SIGINT mode on
main
Thread ID: 5380
funcint
Thread ID: 5380

Смотрим стек вызовов

ntdll.dll!775270f4()
ntdll.dll![Указанные ниже кадры могут быть неверны или отсутствовать, символы для ntdll.dll не загружены]
ntdll.dll!775264a4()
kernel32.dll!76054b6e()
kernel32.dll!760acf97()
kernel32.dll!760ad071()
ucrtbase.dll!0fb5ed35()
ucrtbase.dll!0fb5ec74()
experiment.exe!funcint(int sig)
ucrtbase.dll!0fb2ca9a()
experiment.exe!main()
[Внедренный фрейм] experiment.exe!invoke_main()
experiment.exe!__scrt_common_main_seh()
kernel32.dll!7604ed6c()
ntdll.dll!775437eb()
ntdll.dll!775437be()

Мы видим, что вызов обработчика происходит в основном потоке, посредством библиотеки выполнения C Runtime

Случай, когда сигнал возбужден ядром. Это стандартная ситуация, когда сигнал SIGINT возбуждается при нажатии на клавиатуре CTRL+C при работе консольных приложений. Обработчик запускается в контексте ядра в отдельном потоке.

Вывод

Raise SIGINT mode off
main
Thread ID: 976
funcint
Thread ID: 2848

Смотрим стек вызовов потока 2848

ntdll.dll!775270f4()
ntdll.dll![Указанные ниже кадры могут быть неверны или отсутствовать, символы для ntdll.dll не загружены]
ntdll.dll!775264a4()
kernel32.dll!76054b6e()
kernel32.dll!760acf97()
kernel32.dll!760ad071()
ucrtbase.dll!0fb5ed35()
ucrtbase.dll!0fb5ec74()
experiment.exe!funcint(int sig)
ucrtbase.dll!0fb2c72d()
kernel32.dll!7607e3d8()
kernel32.dll!7604ed6c()
ntdll.dll!775437eb()
ntdll.dll!775437be()

Мы видим, что вызов обработчика происходит в потоке kernel32.dll, посредством библиотеки выполнения C Runtime

Обработка исключения, в зависимости от контекста обработчика сигнала.

int main()
{
#if defined(SIGINT_RAISE)
	printf("Raise SIGINT mode on\n");
#else
	printf("Raise SIGINT mode off\n");
#endif 
	printf("main\n");
	printf("Thread ID: %d\n", _get_thread_id());
	try
	{
		if (signal(SIGABRT, funcabrt) == SIG_ERR) exit(EXIT_FAILURE);
		if (signal(SIGINT, funcint) == SIG_ERR) exit(EXIT_FAILURE);
#if defined(SIGINT_RAISE)
		raise(SIGINT);
#endif 
		while (1); // нажмите CTRL+C вылетит птенец
	}
	catch (int err)
	{
		printf("catch\n");
		_getch();
	};
};

Здесь в том случае, если сигнал сгенерирован программой, возбужденное исключение попадёт в блок try/catch. Причина следует из особенностей, которые я описал в п.1. При возбуждении исключения происходит раскрутка стека, т.е. поиск обработчиков в генерирующей сигнал (и фактически вызвавшей её обработчик) функции.

Вывод

Raise SIGINT mode on
main
Thread ID: 4676
funcint
Thread ID: 4676
catch

А вот если SIGINT сгенерирован ядром, исключение не найдёт своего обработчика и отправится в отладчик, либо будет сгенерирован SIGABRT. Точнее найдёт, возможно, в неграх ядра есть SEH обработчик верхнего уровня (системный), до которого исключение в конце концов добирается и уже этот обработчик производит фактически вызов обработчика SIGABRT, который находится в нашей программе. Однако, зафиксировать этот факт при отладке не представляется возможным.

Обработчик сигнала SIGABRT вызывается, если программа выполняется не под отладчиком.

Возбуждаем пустое исключение.

throw;

Если программа выполняется под отладчиком, неперехваченное исключение попадает в отладчик, т.к. никаких обработчиков для такого исключения не предусмотрено.

Вывод

Raise SIGINT mode off
main
Thread ID: 2940
funcint
Thread ID: 5372

Отладчик

Если программа выполняется без присоединённого отладчика, происходит генерация SIGABRT

void funcabrt(int sig)
// обработчик неперехваченного исключения
{
	_set_abort_behavior(0, _CALL_REPORTFAULT);
	perror("funcabrt");
	printf("Thread ID: %d\n", _get_thread_id());
	_getch();
};

Вывод

Raise SIGINT mode off
main
Thread ID: 5748
funcint
Thread ID: 2732
funcabrt: Result too large
Thread ID: 2732

Итоги:

1. Если мы генерируем сигнал в программе, то обработчик сигнала вызывается как обычная функция Если сигнал генерирует ядро, то обработчик сигнала вызывается в отдельном потоке

2. Если программа выполняется под отладчиком, все сгенерированные и необработанные исключения перехватывает отладчик. Если программа выполняется без отладчика, вызывается обработчик сигнала SIGABRT