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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

Мутипроцессинг или Pyro с распределенными объектами данных.

http://pyro.sourceforge.net/

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

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