Я искал код libstdc ++ и был удивлен, что это устанавливает плохой бит в потоке когда operator>>
или же operator<<
прерывается точкой отмены pthread
(который, если я правильно понимаю, реализуется с помощью специального магического объекта исключения).
Очевидно, стандарт C ++ требует, чтобы исключение, экранирующее соответствующую функцию ввода / вывода, устанавливало бадбит. Но, насколько я понимаю, отмену pthread не нужно рассматривать как «исключение» в смысле C ++.
Означает ли это, что при звонке pthread_cancel
нить, которая использует cout
и друзья, всегда нужно очищать бадбит после того, как поток, выполняющий ввод / вывод, завершился (чтобы быть уверенным, на случай, если поток вызвал установку бита)?
Стандарт C ++ не определяет какого-либо конкретного поведения для специального исключения pthread. Тем не менее, он указывает, что перехват любого исключения приводит к установке std::ios_base::badbit
, Стандарт должен быть расширен для обработки особых исключений. Взаимодействия между различными стандартами, делающими вещи, независимые от C ++ в стандарте C ++, явно выходят за рамки стандарта C ++.
На одном совещании Kona (~ 2006/2007) подробно обсуждалась проблема отмены потоков с помощью исключений. Было установлено, что поддержка отмены потока вызывает странные проблемы и что слишком много вопросов открыто для поддержки отмены потока в C ++. Если вам нужна поддержка каналирования рабочих потоков в C ++, вам необходимо интегрировать ее со стандартом C ++. Впрочем, я не ожидаю большой поддержки отмены потоков в C ++.
Для более практических вопросов я также могу представить, что бросание, например, read(2)
может оставить поток не подозревающей реализации потока ввода / вывода в несогласованном состоянии! Системные функции не использовали, чтобы бросить. Если начать делать такие забавные вещи, может случиться. То есть библиотека stabdard должна знать об этом изменении поведения системных вызовов. Это тихое изменение в поведении было одним из аргументов, почему отмена потока через исключения не считалась жизнеспособным подходом: то, что применимо к стандартной реализации библиотеки C ++, применимо еще больше к пользовательскому коду.
Других решений пока нет …