Я создаю API Python на базе DLL «черного ящика» .NET, используя Python .NET. DLL выполняет только сетевые операции. DLL требует от меня запуска цикла перекачки сообщений Windows, иначе через некоторое время сетевые операции зависают. Я запускаю цикл сообщений Windows, используя System.Windows.Forms.Application.Run() в основном потоке. Это отлично работает только для получения данных. Моя программа начинает вести себя странно, когда я начинаю выполнять вызовы из другого потока Python в DLL. Я думаю, что это связано с многопоточностью, поскольку проблемы возникают очень нерегулярно - сетевые события исчезают или приходят очень поздно. Насколько я знаю, Python и C# потокобезопасны, но, возможно, из-за нескольких слоев упаковки что-то пойдет не так.
Поэтому у меня есть пара вопросов:
Это плохая идея выполнять вызовы DLL из нескольких модулей Python? Или это зависит от внутреннего устройства DLL? Я думал, что с точки зрения DLL потоки Python рассматриваются как единые агенты из-за GIL.
Нужен ли каждому потоку Python, использующему эту DLL, насос сообщений?
Вероятно, было бы неплохо хранить все взаимодействия с DLL в одном потоке. У меня возникают трудности с этим, поскольку я передаю управление циклу насоса сообщений в основном потоке. Мой наивный подход заключался бы в том, чтобы поместить новые исходящие сетевые сообщения, сгенерированные в моем рабочем потоке, в очередь Python, создать собственный цикл перекачки сообщений в основном потоке, который выполняет обработку событий Windows, но также контролирует мою очередь, и если есть сообщение, будет выполняться вызов DLL. Но все это выглядит довольно неуклюже и требует много работы для такой простой задачи. Правильный ли это подход?
Есть ли другой способ поместить в цикл событий главного окна функцию, которая отслеживает ранее описанную очередь и принимает меры? Или мне следует углубиться в особенности .NET и начать использовать события или диспетчеры .NET?
Я создаю API Python на базе DLL «черного ящика» .NET, используя Python .NET. DLL выполняет только сетевые операции. DLL требует от меня запуска цикла перекачки сообщений Windows, иначе через некоторое время сетевые операции зависают. Я запускаю цикл сообщений Windows, используя System.Windows.Forms.Application.Run() в основном потоке. Это отлично работает только для получения данных. Моя программа начинает вести себя странно, когда я начинаю выполнять вызовы из другого потока Python в DLL. Я думаю, что это связано с многопоточностью, поскольку проблемы возникают очень нерегулярно - сетевые события исчезают или приходят очень поздно. Насколько я знаю, Python и C# потокобезопасны, но, возможно, из-за нескольких слоев упаковки что-то пойдет не так.
Поэтому у меня есть пара вопросов:
[list] [*]Это плохая идея выполнять вызовы DLL из нескольких модулей Python? Или это зависит от внутреннего устройства DLL? Я думал, что с точки зрения DLL потоки Python рассматриваются как единые агенты из-за GIL. [*]Нужен ли каждому потоку Python, использующему эту DLL, насос сообщений? [*]Вероятно, было бы неплохо хранить все взаимодействия с DLL в одном потоке. У меня возникают трудности с этим, поскольку я передаю управление циклу насоса сообщений в основном потоке. Мой наивный подход заключался бы в том, чтобы поместить новые исходящие сетевые сообщения, сгенерированные в моем рабочем потоке, в очередь Python, создать собственный цикл перекачки сообщений в основном потоке, который выполняет обработку событий Windows, но также контролирует мою очередь, и если есть сообщение, будет выполняться вызов DLL. Но все это выглядит довольно неуклюже и требует много работы для такой простой задачи. Правильный ли это подход? [*]Есть ли другой способ поместить в цикл событий главного окна функцию, которая отслеживает ранее описанную очередь и принимает меры? Или мне следует углубиться в особенности .NET и начать использовать события или диспетчеры .NET? [/list]
Мобильная версия