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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Используйте multiprocessing

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

http://pyro.sourceforge.net/

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

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