Python: Разделение GUI обрабатывает от процесса логики ядра
Я разрабатываю проект Python для контакта с компьютерными моделированиями, и я также разрабатываю GUI для него. (Сама логика ядра не требует GUI.) Инструментарий GUI, для которого я использую, является wxPython, но я думаю, что мой вопрос является достаточно общим для не зависимости от него.
Способ, которым в настоящее время работает GUI, состоит в том, что он запускает пакет логики ядра (названный garlicsim) на том же процессе и том же потоке как GUI. Это работает, но я понимаю, что это - проблематичный подход, потому что, если логика ядра должна сделать некоторое трудное вычисление, GUI зависнет, который я считаю недопустимыми.
Что я должен сделать?
Я слышал об опции о запуске логики ядра на отдельном процессе от GUI. Это звучит интересным, но у меня есть много вопросов об этом.
- Сделайте я использую
multiprocessingпакет илиsubprocessпакет для запуска нового процесса? - Как у меня есть легкий доступ к данным моделирования из процесса GUI? В конце концов, это будет сохранено на другом процессе. Пользователь должен быть в состоянии просмотреть временную шкалу моделирования легко и гладко. Как это может быть сделано?
5 ответов
Самый простой подход, который может сработать для вас, - запустить вычисление в отдельном потоке и передать данные между этим потоком и графическим интерфейсом пользователя с помощью объектов Queue . Они полностью безопасны и очень удобны для межпоточного взаимодействия.
Другие решения более сложны - вы можете запустить моделирование в полностью отдельном «серверном» процессе и взаимодействовать с сокетами с основным графическим интерфейсом пользователя.
Здесь можно найти вдохновение: http://wiki.wxpython.org/LongRunningTasks, однако это для многопоточности, а не для многопроцессорности.
Основная идея
- для многопоточности: использовать очередь событий для связи между графическим интерфейсом и потоком обработки.
- для многопроцессорности: возможно использовать пакет подпроцесса , а для связи с ним использовать stdin/stdout дочернего процесса. Для этого вам нужна командная строка api, но в конце концов она пригодится, потому что вы можете выполнять gui-независимое тестирование модулей.
Вы даже можете прогнать соединение i/o через сокет, это позволит легко управлять симуляцией по сети.
Правка: Я только что видел 2.6-новый пакет multiprocessing, о котором вы упоминали. Хороший выбор, тогда можно было бы использовать очереди для взаимодействия между процессами. Это более тесная связь, вы можете выбирать в зависимости от ваших потребностей.
Для ответа на конкретные вопросы
"Использую ли я для запуска нового процесса пакет для многопроцессорной обработки или пакет для подпроцесса ? "
Используйте мультипроцесс
"Как мне получить легкий доступ к данным моделирования из GUI-процесса?"
У вас нет доступа к объектам моделирования процессов, если вы об этом спрашиваете Моделирование - это отдельный процесс. Вы можете запустить его, остановить и - самое главное - сделать запросы через очередь команд, которые идут к симулятору
"Пользователь должен иметь возможность легко и гладко просматривать временную шкалу симуляции. Как это можно сделать?"
Это всего лишь дизайн. Одиночный процесс, несколько процессов, несколько потоков никак не влияют на этот вопрос.
- Каждое моделирование должно иметь некоторые параметры, оно должно начинаться, оно должно производить лог (или временную шкалу). Это должно быть сделано независимо от того, какую библиотеку вы используете для запуска и остановки симуляции.
Выходные данные из симуляции -- которые вводятся в ваш графический интерфейс -- могут быть сделаны миллионом способов.
База данных. Временная шкала моделирования может быть вставлена в базу данных SQLite и запрошена в GUI. Это не очень хорошо работает, потому что у SQLite нет действительно умной блокировки. Но это работает.
Файл. Хронология моделирования записывается в файл. GUI читает файл. Это работает очень, очень хорошо.
Request/Reply. В симуляции есть несколько потоков, один из которых - вычисляет команды и отвечает -- например -- посылает временную шкалу назад до момента, или останавливает симуляцию, или изменяет параметры и перезапускает ее.
К сожалению, хотя вы правы, что выбор графического интерфейса не влияет на ответ, лучший подход к этой проблеме будет во многом зависеть от того, что именно делают ваши симуляционные данные.
Например, если он генерирует последовательные данные, то может подавать их в ваш графический интерфейс через потокобезопасную или процессно-безопасную очередь. Но если он мутирует все данные, и ваш графический интерфейс должен быть способен видеть снимки в любой момент времени, то это может быть слишком дорогостоящим решением, чтобы решить проблему, посылая все состояние вдоль очереди, и может потребоваться подход в стиле мьютекса, вместо того, чтобы совместно использовать доступ к структуре данных. Поэтому природа работы с вашими данными здесь имеет первостепенное значение.
Что касается того, использовать ли мультипроцесс или подпроцесс, то это зависит от того, есть ли у вас полностью отдельная программа или нет, обрабатывающая данные. Первое предназначено для выполнения многопроцессорной обработки в стиле многопоточности - это разные части одной и той же программы, выполняемые в нескольких процессах. Вторая - когда одна программа хочет запустить другую (которая может быть копией программы, но обычно не является таковой). Опять же, трудно понять, какой подход лучше всего подходит для вашей конкретной ситуации, хотя звучит так, как будто вы могли бы иметь ядро логики как приложение командной строки и общаться через каналы, сокеты и т.д.
.Mutiprocessing или Pyro с распределенными объектами данных.
Ваше моделирование поставляет распределенные объекты в GUI, GUI манипулирует ими и читает их атрибуты.
Обе библиотеки обеспечат расширяемость по сети без лишних хлопот, но могут работать локально. Когда ваша симуляция начнет скрипеть слишком много чисел, добавьте больше серверов симуляции, которые предоставляют больше распределенных объектов
.