Есть ли обходные пути для выбора Python и обработки EINTR в Linux?
В одном из моих недавних проектов я участвовал в том же процессе (программа на Python, это многопоточное приложение):
модуль Boost::Python для библиотеки, которая связана с AVT PvAPI SDK, т.е. в самом широком смысле это драйвер для получения кадров изображения с камеры. Эта библиотека (PvApi SDK) генерирует SIGALRM внутри себя каждые несколько миллисекунд.
другой простой модуль Python, предназначенный для выполнения некоторых последовательных операций ввода-вывода с использованием pyserial. Это, в свою очередь, использует обертку Python select.select для POSIX select. Который оказался прерван (
errno == EINTR) каждый раз, когда сигнал генерируется другим модулем.та же проблема может наблюдаться при любом вызове Python time.sleep, соответственно. сон POSIX, который используется внутри.
Эти проблемы, по-видимому, отсутствуют в Windows, так как спящий режим и выбор не будут прерваны никаким сигналом (согласно документации). И эти проблемы не являются большой проблемой в C/C++, так как вы можете (и должны, хотя) перезапускать вызовы, если они были прерваны.
Однако, поскольку реализация Python ( исходный код /Modules/selectmodule.c) не обрабатывает этот случай (EINTR), я вынужден реализовать свой собственный последовательный драйвер C / C++ и функцию сна для использования в Python? Или отойти от Python для этого проекта? Поскольку Python делает программирование намного проще, я очень заинтересован, если у кого-нибудь возникнут подобные проблемы и найдется хороший обходной путь или простое решение для этого. Сейчас у меня нет возможности самостоятельно разработать необходимые исправления для модулей Python. Или, может быть, я пропустил какой-то другой вариант?
Есть идеи?
2 ответа
Попробуйте использовать signal.sigintterupt сделать SIGALRM сигнал перезапуска системных вызовов автоматически. Или вы могли бы использовать signal.signal(signal.SIGALRM, signal.SIG_IGN) игнорировать сигнал тревоги, предполагая, что вы не используете его ни для чего.
Тем временем для решения этой проблемы был опубликован PEP (PEP 475).
Судя по всему, это поведение было исправлено, начиная с Python 3.5 в 2015 году.