Python: разделение процесса графического интерфейса от основного логического процесса

Question

Я разрабатываю Python project для работы с компьютерными симуляторами, и я также разрабатываю для него графический интерфейс. (Сама логика ядра не требует графического интерфейса.) Инструмент GUI, который я использую для wxPython, но я думаю, что мой вопрос достаточно общий, чтобы не зависеть от него.

Способ, которым в настоящее время работает графический интерфейс, заключается в том, что он запускает основной пакет логики (называемый garlicsim) в том же процессе и в том же потоке, что и графический интерфейс. Это работает, но я понимаю, что это проблематичный подход, потому что, если основной логике нужно делать какие-то жесткие вычисления, GUI будет зависать, что я считаю неприемлемым.

Что мне делать?

Я слышал о возможности запуска основной логики в отдельном процессе из графического интерфейса. Это звучит интересно, но у меня есть много вопросов об этом.

1. Я использую multiprocessing пакет или subprocess пакет для запуска нового процесса делать?
2. Как мне легко получить доступ к данным моделирования из процесса GUI? В конце концов, он будет сохранен на другом процессе. Пользователь должен иметь возможность просматривать график времени моделирования легко и плавно. Как это может быть сделано?

Answer 1

Возможно, вы нашли здесь свое вдохновение: http://wiki.wxpython.org/LongRunningTasks, однако он предназначен для многопоточности, а не для многопроцессорности.

Основная идея

• многопоточности: использование очереди событий для обмена данными между графическим интерфейсом и обработки потока.
• для многопроцессорной обработки: возможно, используйте подпроцесс и используйте stdin/stdout дочернего процесса для связи с ним. Для этого вам нужна командная строка api, но в конце концов это пригодится, потому что вы можете сделать независимое от группы модульное тестирование.

Вы можете даже управлять связью ввода/вывода через сокет, это позволило бы легко управлять сетью моделирования.

Edit: Я только увидел 2,6-новый многопроцессорных пакет вы упомянули. Кажется приятным выбором, вы могли бы использовать очереди для связи между процессом. Это более плотная связь, которую вы можете выбрать в зависимости от ваших потребностей.

Answer 2

К сожалению, хотя вы правы в том, что выбор графического интерфейса не влияет на ответ, лучший подход к этой проблеме будет зависеть от того, что именно делают ваши данные моделирования.

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

Что касается использования многопроцессорности или подпроцесса, это зависит от того, есть ли у вас полностью отдельная программа или нет обработки данных.Первая предназначена для многопроцессорности в стиле многопоточности - это разные части одной и той же программы, работающей в нескольких процессах. Последнее - когда одна программа хочет запустить другую (которая может быть быть копией программы, но обычно это не так). Опять же, трудно понять, какой из них лучше всего подходит для вашей конкретной ситуации, хотя звучит так, как будто вы можете использовать основную логику в качестве приложения командной строки и общаться через трубы, розетки и т. Д.

Answer 3

Чтобы ответить на конкретные вопросы ,

«Я использую пакет multiprocessing или пакет subprocess для запуска нового процесса?»

Использование multiprocessing

«Как у меня есть легкий доступ к данным моделирования из процесса графического интерфейса?»

У вас нет доступа к объектам процессов моделирования, если это то, что вы просите. Моделирование - это отдельный процесс. Вы можете запустить его, остановить его и, самое главное, делать запросы через очередь команд, которые идут на симулятор.

«Пользователь должен иметь возможность легко и плавно просматривать график времени моделирования. Как это можно сделать?»

Это просто дизайн. Один процесс, несколько процессов, несколько потоков не имеют никакого влияния на этот вопрос.

Каждое моделирование должно иметь некоторые параметры, оно должно начинаться, оно должно создавать журнал (или временную шкалу). Это должно быть сделано независимо от того, какую библиотеку вы используете для запуска и прекращения моделирования.

Результат моделирования - который вводится в ваш графический интерфейс - можно сделать миллионным способом.

• База данных. Временная шкала моделирования может быть вставлена ​​в базу данных SQLite и запрошена графическим интерфейсом. Это не очень хорошо работает, потому что SQLite не имеет действительно умной блокировки. Но это действительно работает.

• Файл. Временная шкала моделирования записывается в файл. GUI читает файл. Это работает действительно, очень хорошо.

• Запрос/Ответ. Моделирование имеет несколько потоков, одна из которых выполняет команды по развязыванию и отвечает, например, - отсылает временную шкалу до момента или останавливает симуляцию или меняет параметры и перезапускает ее.

Answer 4

Самый простой подход, который может работать для вас здесь запустить вычисление в отдельном потоке, а также обмениваться данными между этим потоком и графического интерфейса с помощью Queue объектов. Они полностью безопасны и очень удобны для межпоточной связи.

Другие решения сложнее - вы можете запустить симуляцию в совершенно отдельный «серверный» процесс и связаться с сокетами с основным графическим интерфейсом.

Answer 5

Mutiprocessing or Pyro с распределенными объектами данных.

http://pyro.sourceforge.net/

Ваши поставки моделирования распределенных объектов в GUI, графический интерфейс манипулирует ими и читает их атрибуты.

Обе библиотеки обеспечат расширяемость по сети без каких-либо проблем, но могут работать локально. Когда ваше симуляция начнет хрустить слишком много чисел, добавьте больше серверов имитации, которые предоставляют более распределенные объекты.