Поведение C ++ const static после завершения программы

У меня есть программа, которая создает поток (я использую библиотеку C ++ Boost для создания потоков) при запуске. В основной программе я зарегистрировал свою функцию очистки как.

atexit(cleanExit)
// Trap some signals for a clean exit.
signal(SIGQUIT, signalled)
signal(SIGABRT, signalled)
signal(SIGTERM, signalled)
signal(SIGINT, signalled)

static void signalled(int signal)
{
exit(signal)
}
static void cleanExit(void)
{
thread->interrupt();
thread->join();
}

Как вы можете видеть выше во время процесса чистого выхода, я прерываю поток и затем жду здесь (в основном процессе), чтобы поток выполнял свою работу по очистке. Когда я вызываю thread-> interrupt, мой поток прерывается, и я выполняю очистку потока. До сих пор все работает без проблем.

Но проблема возникает, когда я вызываю функцию очистки в потоке. В функции очистки я отправляю некоторый статус обратно на сервер, для этого я создал служебную функцию. В этой служебной функции я обращаюсь к члену класса «const static string». Проблема в том, что когда я получаю доступ к этой статической статической строке, мое приложение просто зависает. Я проверил с помощью strace, и я получаю Seg Fault. Но когда я изменяю эту «const static string» на «const string», моя очистка проходит гладко.

ВОПРОС
Каково поведение C ++ «const static» после завершения программы. Сдаются ли они, когда вызывается exit (что можно увидеть в приведенном выше случае), или какие-либо мысли об этом поведении.

Вот функция обработчика потока. Как я уже упоминал выше, это тема Boost.

try {
while ( true ) {
// Do your job here.
// 1: We can be interrupted.
boost::this_thread::interruption_point();
}
}
catch (boost::thread_interrupted const& )
{
// Before exiting we need to process all request messages in the queue
completeAllWorkBeforeExiting();
}

Когда основная программа вызывает thread-> interrupt, поток вызовет исключение thread_interrupted в # 1, и, перехватывая это исключение, я занимаюсь очисткой.

1

Решение

const не влияет, когда какой-либо объект уничтожен.

static объекты уничтожаются в порядке, противоположном порядку их создания. atexit по сути создает анонимный static объект с заданной функцией в качестве деструктора. То есть, static деструкторы объекта и atexit Обратные вызовы происходят в порядке, противоположном их построению / регистрации.

Совершенно небезопасно звонить exit из обработчика сигнала. Все, что обработчику сигналов практически разрешено делать, — это установить флаг, который позже опрашивается потоками. Как вы уже упоминали, обработчик сигнала выполняется во время прерывания, поэтому он может прерывать системный вызов. Это может прервать malloc таким образом, что обходит mallocМногопоточные блокировки, так как вход в один поток, а не другой, как обычно бывает.

Так что это источник всех видов непредсказуемого поведения. Не видя больше, я не могу более конкретно сказать, какой эффект static имеет, но, вероятно, это как-то связано с изменением времени жизни объекта и / или созданием его экземпляра один раз для каждого объекта.

2

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector