Потоки qt: Qt/C++ — Урок 047. QThread

используйте потоки Qt или потоки Python? Ru Python

Это было обсуждено не так давно в списке рассылки PyQt. Цитируя комментарии Джованни Баджо на эту тему:

Это в основном то же самое. Основное отличие состоит в том, что QThreads лучше интегрированы с Qt (асинхронные сигналы / слоты, цикл событий и т. Д.). Кроме того, вы не можете использовать Qt из потока Python (вы не можете, например, отправить событие в основной поток через QApplication.postEvent): для работы вам нужен QThread.

Общее правило может заключаться в использовании QThreads, если вы собираетесь каким-то образом взаимодействовать с Qt и использовать потоки Python в противном случае.

И некоторые более ранние комментарии по этому вопросу от автора PyQt: «они оба обертки вокруг тех же реализаций собственных потоков». И обе реализации используют GIL таким же образом.

Нити Python будут проще и безопаснее, и поскольку они предназначены для приложения на основе ввода-вывода, они могут обойти GIL.

EDIT: больше по потокам

Нити Python

Потоки Python – это системные потоки. Тем не менее, Python использует глобальную блокировку интерпретатора (GIL), чтобы гарантировать, что интерпретатор выполняет только определенный блок размера инструкций байтового кода за раз. К счастью, Python выпускает GIL во время операций ввода-вывода, делая потоки полезными для имитации неблокирующего ввода-вывода.

Важное предупреждение: это может ввести в заблуждение, так как количество инструкций байт-кода не соответствует количеству строк в программе. Даже одно назначение не может быть атомарным в Python, поэтому блокировка мьютекса необходима для любого блока кода, который должен выполняться атомарно, даже с GIL.

Потоки QT

Когда Python отключает управление сторонним компилированным модулем, он выпускает GIL. В обязанности модуля входит обеспечение атомарности, когда это необходимо. Когда управление передается обратно, Python будет использовать GIL. Это может сделать использование сторонних библиотек в связи с запутанностью потоков. Еще сложнее использовать внешнюю библиотеку потоков, поскольку она добавляет неопределенность относительно того, где и когда управление находится в руках модуля и интерпретатора.

Потоки QT работают с выпущенным GIL. Потоки QT могут выполнять код библиотеки QT (и другой код скомпилированного модуля, который не получает GIL) одновременно. Тем не менее, код Python, выполняемый в контексте потока QT, по- прежнему приобретает GIL, и теперь вам нужно управлять двумя наборами логики для блокировки вашего кода.

В конце концов, как потоки QT, так и потоки Python являются обертками вокруг потоков системы. Потоки Python являются более безопасными для использования, поскольку те части, которые не написаны на Python (неявно использующие GIL), используют GIL в любом случае (хотя вышеописанное предостережение применяется).

Неблокирующий ввод-вывод

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

С асинхронным вводом-выводом вы всегда можете быть уверены, что для каждого открытого дескриптора путь выполнения согласован и упорядочен. Есть, очевидно, проблемы, которые необходимо решить, например, что делать, когда код, зависящий от одного открытого канала, зависит от результатов кода, который будет вызываться, когда другой открытый канал возвращает данные.

Одним из прекрасных решений для ввода-вывода без событий, основанных на событиях, является новая библиотека Diesel . На данный момент он ограничен Linux, но он необычайно быстрый и довольно элегантный.

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

Я задал себе тот же вопрос, когда работал над PyTalk .

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

С движком сигнала / слота вы сможете разговаривать из потока в другой и с каждой частью вашего проекта.

Более того, вопрос об этом выборе очень невелик, так как оба являются связями C ++.

Вот мой опыт PyQt и потока.

Я рекомендую вам использовать QThread .

Я тоже не могу рекомендовать, но я могу попытаться описать различия между потоками CPython и Qt.

Прежде всего, потоки CPython не запускаются одновременно, по крайней мере, не с кодом Python. Да, они создают системные потоки для каждого потока Python, однако разрешен запуск только потока, в котором сейчас выполняется Global Interpreter Lock (расширения C и код FFI могут обходить его, но байт-код Python не выполняется, пока поток не содержит GIL).

С другой стороны, у нас есть потоки Qt, которые в основном являются общими для системных потоков, не имеют Global Interpreter Lock и, таким образом, могут работать одновременно. Я не уверен, как PyQt справляется с этим, однако, если ваши потоки Qt не назовут код Python, они должны иметь возможность запускать одновременно (блокировать различные дополнительные блокировки, которые могут быть реализованы в различных структурах).

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

Надеюсь, что это поможет с вашими проблемами 🙂

использовать потоки Qt или потоки Python?

Потоки Python будут проще и безопаснее, и, поскольку они предназначены для приложений на основе ввода-вывода, они могут обходить GIL. Тем не менее, рассматривали ли вы неблокирующий ввод-вывод с использованием Twisted или неблокирующих сокетов / select?

РЕДАКТИРОВАТЬ: подробнее о потоках

Потоки Python

Потоки Python — это системные потоки. Однако Python использует глобальную блокировку интерпретатора (GIL), чтобы гарантировать, что интерпретатор одновременно выполняет только блок инструкций байтового кода определенного размера. К счастью, Python выпускает GIL во время операций ввода / вывода, делая потоки полезными для моделирования неблокирующего ввода / вывода.

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

QT потоки

Когда Python передает управление стороннему скомпилированному модулю, он освобождает GIL. Ответственность за обеспечение атомарности там, где это необходимо, ложится на модуль. Когда управление будет передано обратно, Python будет использовать GIL. Это может сбивать с толку использование сторонних библиотек в сочетании с потоками. Еще сложнее использовать внешнюю библиотеку потоков, потому что это добавляет неопределенности относительно того, где и когда управление находится в руках модуля, а не интерпретатора.

Потоки QT работают с выпущенным GIL. Потоки QT могут выполнять код библиотеки QT (и другой код скомпилированного модуля, который не получает GIL) одновременно. Однако код Python, выполняемый в контексте потока QT, по- прежнему получает GIL, и теперь вам нужно управлять

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

Неблокирующий ввод / вывод

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

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

Хорошим решением для событийного неблокирующего ввода-вывода является новая библиотека Diesel . На данный момент он ограничен Linux, но он необычайно быстр и довольно элегантен.

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

python — Потоки в приложении PyQt: Использовать потоки Qt или потоки Python?

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

[Да, я знаю, сейчас у меня две проблемы а> . ]

В любом случае, приложение использует PyQt4, поэтому я хотел бы знать, какой вариант лучше: использовать потоки Qt или использовать модуль Python threading? Каковы преимущества / недостатки каждого? Или у тебя совершенно другое предложение?

Изменить (re bounty). Хотя в моем конкретном случае решение, вероятно, будет использовать неблокирующий сетевой запрос, например Джефф Обер и предложил Лукаш Лалинский (так что, в сущности, оставляя проблемы с параллелизмом для сетевой реализации), я бы по-прежнему как более глубокий ответ на общий вопрос:

Каковы преимущества и недостатки использования потоков PyQt4 (т.е. Qt) по сравнению с собственными потоками Python (из модуля threading)?

Изменить 2 . Спасибо всем за ответы. Хотя не существует 100% -ого согласия, похоже, что существует широко распространенное мнение, что ответом является «использовать Qt», поскольку его преимущество заключается в интеграции с остальной частью библиотеки, не вызывая при этом реальных недостатков.

Для тех, кто хочет выбрать между двумя реализациями потоков, я настоятельно рекомендую прочитать все ответы, представленные здесь, включая ветку списка рассылки PyQt, которая abbot ссылается на.

Было несколько ответов, которые я рассмотрел для награды; в конце концов я выбрал настоятеля для очень релевантной внешней ссылки; это был, однако, близкий звонок.

Еще раз спасибо.

120

balpha 20 Окт 2009 в 19:54

7 ответов

Лучший ответ

Это обсуждалось не так давно в списке рассылки PyQt. Цитируя комментарии Джованни Баджо на эту тему:

Это в основном то же самое. Основное отличие состоит в том, что QThreads лучше интегрированы с Qt (асинхронные сигналы / слоты, цикл обработки событий и т. Д.). Кроме того, вы не можете использовать Qt из потока Python (например, вы не можете публиковать события в главном потоке через QApplication. postEvent): вам нужен QThread, чтобы это работало.

Общее практическое правило может заключаться в использовании QThreads, если вы собираетесь каким-либо образом взаимодействовать с Qt, и в противном случае использовать потоки Python.

И некоторые ранее прокомментировали эту тему от автора PyQt: «они оба являются обертками вокруг одних и тех же собственных реализаций потоков». И обе реализации используют GIL одинаково.

110

abbot 3 Апр 2012 в 15:33

Я не могу прокомментировать точные различия между потоками Python и PyQt, но я делал то, что вы пытаетесь сделать, используя QThread, QNetworkAcessManager и проверяя, чтобы вызвать QApplication.processEvents() пока нить жива. Если реакция GUI действительно является проблемой, которую вы пытаетесь решить, позже поможет.

0

brianz 25 Окт 2009 в 05:24

Я тоже не могу рекомендовать, но я могу попытаться описать различия между потоками CPython и Qt.

Прежде всего, потоки CPython не работают одновременно, по крайней мере, не код Python. Да, они создают системные потоки для каждого потока Python, однако разрешено запускать только поток, в настоящее время содержащий глобальную блокировку интерпретатора (расширения C и код FFI могут его обойти, но байт-код Python не выполняется, пока поток не содержит GIL).

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

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

Надеюсь, это поможет с вашими проблемами 🙂

5

p_l 28 Окт 2009 в 09:15

У Джеффа есть несколько хороших моментов. Только один основной поток может выполнять любые обновления графического интерфейса. Если вам нужно обновить графический интерфейс из потока, Qt-4 сигналы подключения в очереди упрощают отправку данных между потоками и будут автоматически вызываться, если вы используете QThread; Я не уверен, будут ли они, если вы используете потоки Python, хотя добавить параметр в connect() легко.

9

ekhumoro 19 Янв 2017 в 17:29

Я задавал себе тот же вопрос, когда работал над PyTalk.

Если вы используете Qt, вам нужно использовать QThread, чтобы иметь возможность использовать каркас Qt и особенно систему сигналов / слотов.

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

Более того, вопрос об этом выборе не очень высок, поскольку оба являются привязками C ++.

Вот мой опыт PyQt и потока.

Я рекомендую вам использовать QThread.

14

Natim 27 Окт 2009 в 01:17

Преимущество QThread заключается в том, что он интегрирован с остальной частью библиотеки Qt. То есть методы с поддержкой потоков в Qt должны будут знать, в каком потоке они работают, и для перемещения объектов между потоками вам нужно будет использовать QThread. Еще одна полезная функция — запуск собственного цикла событий в потоке.

Если вы обращаетесь к HTTP-серверу, вы должны рассмотреть QNetworkAccessManager.

21

Lukáš Lalinský 20 Окт 2009 в 16:11

Потоки Python будут проще и безопаснее, и, поскольку они предназначены для приложений на основе ввода / вывода, они могут обходить GIL. Тем не менее, вы рассматривали неблокирующие операции ввода-вывода с использованием витых или неблокирующих сокетов / select?

РЕДАКТИРОВАТЬ: больше о темах

Темы Python

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

Важное предупреждение: Это может вводить в заблуждение, поскольку число инструкций байт-кода не соответствует количеству строк в программе. Даже одно назначение не может быть атомарным в Python, поэтому блокировка мьютекса необходима для любого блока кода, который должен выполняться атомарно, даже с GIL.

Темы QT

Когда Python передает управление стороннему скомпилированному модулю, он освобождает GIL. Модуль несет ответственность за обеспечение атомарности, где это необходимо. Когда управление передается обратно, Python будет использовать GIL. Это может затруднить использование сторонних библиотек в сочетании с потоками. Еще сложнее использовать внешнюю библиотеку потоков, поскольку она добавляет неопределенность относительно того, где и когда управление находится в руках модуля против интерпретатора.

Потоки QT работают с освобожденным GIL. Потоки QT могут выполнять код библиотеки QT (и другой код скомпилированного модуля, который не получает GIL) одновременно. Однако код Python, выполняемый в контексте потока QT still , получает GIL, и теперь вам нужно управлять двумя наборами логики для блокировки вашего кода.

В конце и потоки QT, и потоки Python являются обертками вокруг системных потоков. Потоки Python немного безопаснее в использовании, поскольку те части, которые не написаны на Python (неявно используют GIL), в любом случае используют GIL (хотя оговорка выше все еще применима).

Неблокирующий ввод / вывод

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

Благодаря асинхронному вводу-выводу вы всегда можете быть уверены, что для каждого открытого дескриптора путь выполнения является согласованным и упорядоченным. Очевидно, есть проблемы, которые необходимо решить, например, что делать, когда код, зависящий от одного открытого канала, далее зависит от результатов кода, вызываемого, когда другой открытый канал возвращает данные.

Хорошим решением для неблокирующего ввода-вывода на основе событий является новая дизельная библиотека. На данный момент он ограничен Linux, но он чрезвычайно быстрый и довольно элегантный.

Также стоит потратить время на изучение pyevent — обертки вокруг замечательной библиотеки libevent, которая предоставляет базовая основа для программирования на основе событий с использованием самого быстрого метода, доступного для вашей системы (определяется во время компиляции).

34

Jeff Ober 29 Окт 2009 в 11:52

Класс QMediaStreamsControl | Qt Мультимедиа 5.

Класс QMediaStreamsControl предоставляет элемент управления выбором медиапотока. Подробнее …

Этот класс устарел. Он предназначен для сохранения работоспособности старого исходного кода. Мы настоятельно не рекомендуем использовать его в новом коде.

Открытые типы

Открытые функции

Сигналы

Защищенные функции

Макросы

Подробное описание

Класс QMediaStreamsControl предоставляет описания доступных медиапотоков и позволяет активировать и деактивировать отдельные потоки.

Имя интерфейса QMediaStreamsControl — org. qt-project.qt.mediastreamscontrol / 5.0 , как определено в QMediaStreamsControl_iid.

См. Также QMediaService :: requestControl ().

Документация по типу элемента

QMediaStreamsControl :: StreamType

Тип медиапотока.

Документация по функциям-членам

Создает новый элемент управления потоками мультимедиа с заданным родительским элементом .

Сигнал излучается при изменении списка активных потоков.

Сигнал излучается при изменении списка доступных потоков.

Уничтожает элемент управления медиа-потоками.

Возвращает истину, если медиапоток streamNumber активен.

Возвращает значение метаданных ключа для данного streamNumber .

Полезные ключи метаданных: QMediaMetaData :: Title, QMediaMetaData :: Description и QMediaMetaData :: Language.

Устанавливает активное состояние медиапотока streamNumber .

Установка для активного состояния медиапотока значения true активирует его. Если ранее был активен какой-либо другой поток того же типа, он будет деактивирован. Установка активного состояния медиапотока на false деактивирует его.

См. Также isActive ().

Возвращает количество медиапотоков.

Вернуть тип медиапотока streamNumber .

Макро-документация

QMediaStreamsControl_iid

org.qt-project.qt.mediastreamscontrol / 5.0

Определяет имя интерфейса класса QMediaStreamsControl.

© 2021 Компания Qt Company Ltd. Вклад в документацию, включенный в этот документ, является собственностью их владельцы. Представленная здесь документация лицензирована в соответствии с условиями лицензии GNU Free Documentation License версии 1.3, опубликованной Free Software Foundation.Qt и соответствующие логотипы являются товарными знаками компании Qt Company Ltd. в Финляндии и / или других странах по всему миру. Все остальные товарные знаки являются собственностью их владельцев.

Класс QFileDevice | Qt Core 5.15.4

Класс QFileDevice предоставляет интерфейс для чтения и записи в открытые файлы. Подробнее …

Этот класс был представлен в Qt 5.0.

Документация по типу элемента

перечисление QFileDevice :: FileError

Это перечисление описывает ошибки, которые могут быть возвращены функцией error ().

перечисление QFileDevice :: FileHandleFlag

Это перечисление используется при открытии файла для указания дополнительных параметров, которые применяются только к файлам, а не к общему QIODevice.

Тип FileHandleFlags - это typedef для QFlags . Он хранит комбинацию значений FileHandleFlag по ИЛИ.

перечисление QFileDevice :: FileTime

Это перечисление используется функциями fileTime () и setFileTime ().

Это перечисление было введено или изменено в Qt 5.10.

См. Также setFileTime (), fileTime () и QFileInfo :: fileTime ().

QFileDevice :: MemoryMapFlags

Это перечисление описывает специальные параметры, которые могут использоваться функцией map ().

Это перечисление было введено или изменено в Qt 4.4.

перечисление QFileDevice :: Permission

Это перечисление используется функцией permission () для сообщения о разрешениях и владении файлом. Значения могут быть объединены оператором ИЛИ для проверки нескольких значений разрешений и владения.

Предупреждение: Из-за различий в платформах, поддерживаемых Qt, семантика ReadUser, WriteUser и ExeUser зависит от платформы: в Unix возвращаются права владельца файла, а в Windows - права текущего пользователя. возвращаются.Это поведение может измениться в будущей версии Qt.

Примечание: В файловых системах NTFS проверка прав собственности и разрешений по умолчанию отключена из соображений производительности. Чтобы включить его, включите следующую строку:

 внешний Q_CORE_EXPORT int qt_ntfs_permission_lookup; 

Проверка разрешений затем включается и выключается путем увеличения и уменьшения qt_ntfs_permission_lookup на 1.

 qt_ntfs_permission_lookup ++;
qt_ntfs_permission_lookup--; 

Тип разрешений - это typedef для QFlags .Он хранит комбинацию значений разрешений по ИЛИ.

Документация по функциям-членам

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

Переопределения: QIODevice :: atEnd () const.

Возвращает true , если достигнут конец файла; в противном случае возвращает false.

Для обычных пустых файлов в Unix (например,грамм. те, что в / proc ), эта функция возвращает true , поскольку файловая система сообщает, что размер такого файла равен 0. Следовательно, вы не должны зависеть от atEnd () при чтении данных из такого файла, а скорее вызывайте read () до тех пор, пока не перестанут считываться данные.

Переопределения: QIODevice :: close ().

Вызывает QFileDevice :: flush () и закрывает файл. Ошибки сброса игнорируются.

См. Также QIODevice :: close ().

QFileDevice :: FileError QFileDevice :: error () const

Возвращает состояние ошибки файла.

Состояние устройства ввода-вывода возвращает код ошибки. Например, если open () возвращает false или операция чтения / записи возвращает -1, эту функцию можно вызвать, чтобы выяснить причину сбоя операции.

См. Также unsetError ().

Возвращает имя файла.Реализация по умолчанию в QFileDevice возвращает пустую строку.

QDateTime QFileDevice :: fileTime (QFileDevice :: FileTime

Возвращает время файла, указанное время . Если время не может быть определено, верните QDateTime () (недопустимая дата и время).

Эта функция была представлена ​​в Qt 5.10.

См. Также setFileTime (), FileTime и QDateTime :: isValid ().

bool QFileDevice :: flush ()

Сбрасывает все буферизованные данные в файл.В случае успеха возвращает true ; в противном случае возвращает false .

int QFileDevice :: handle () const

Возвращает дескриптор файла.

Это небольшое положительное целое число, подходящее для использования с функциями библиотеки C, такими как fdopen () и fcntl () . В системах, которые используют файловые дескрипторы для сокетов (например, системы Unix, но не Windows), дескриптор также может использоваться с QSocketNotifier.

Если файл не открыт или произошла ошибка, handle () возвращает -1.

См. Также QSocketNotifier.

Переопределения: QIODevice :: isSequential () const.

Возвращает true , если с файлом можно работать только последовательно; в противном случае возвращает false .

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

См. Также QIODevice :: isSequential ().

uchar * QFileDevice :: map (qint64

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

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

Любые параметры отображения могут быть переданы через флагов .

Возвращает указатель на память или nullptr в случае ошибки.

См. Также unmap ().

Возвращает полную комбинацию OR-ed вместе QFile :: Permission для файла.

См. Также setPermissions ().

Переопределения: QIODevice :: pos () const.

Переопределения: QIODevice :: readData (char * data, qint64 maxSize).

Переопределения: QIODevice :: readLineData (char * data, qint64 maxSize).

Устанавливает размер файла (в байтах) sz .Возвращает true , если изменение размера выполнено успешно; в противном случае - ложь. Если sz больше, чем текущий файл, новые байты будут установлены в 0; если sz меньше, файл просто обрезается.

Предупреждение: Эта функция может завершиться ошибкой, если файл не существует.

См. Также размер ().

Переопределения: QIODevice :: seek (qint64 pos).

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

Поиск за пределами конца файла: если позиция находится за пределами конца файла, функция seek () не будет немедленно расширять файл. Если запись выполняется в эту позицию, файл будет расширен. Содержимое файла между предыдущим концом файла и вновь записанными данными НЕОПРЕДЕЛЕННО и варьируется в зависимости от платформы и файловой системы.

bool QFileDevice :: setFileTime (const QDateTime &

Устанавливает время файла, заданное параметром fileTime , равным newDate , возвращая истину в случае успеха; в противном случае возвращает false.

Примечание: Для использования этой функции файл должен быть открыт.

Эта функция была представлена ​​в Qt 5.10.

См. Также fileTime () и FileTime.

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

Предупреждение: Эта функция не управляет списками ACL, что может ограничить ее эффективность.

См. Также разрешения ().

Переопределения: QIODevice :: size () const.

Возвращает размер файла.

Для обычных пустых файлов в Unix (например, в / proc ) эта функция возвращает 0; содержимое такого файла создается по запросу в ответ на ваш вызов read ().

bool QFileDevice :: unmap (uchar *

Отключает отображение памяти по адресу .

Возвращает true , если unmap успешно; в противном случае - ложь.

См. Также карту ().

void QFileDevice :: unsetError ()

Устанавливает для файла ошибку QFileDevice :: NoError.

См. Также ошибку ().

Переопределения: QIODevice :: writeData (const char * data, qint64 maxSize).

Класс QTemporaryFile | Qt Core 5.15.4

Класс QTemporaryFile - это устройство ввода-вывода, которое работает с временными файлами. Подробнее ...

Подробное описание

QTemporaryFile используется для безопасного создания уникальных временных файлов. Сам файл создается путем вызова open (). Имя временного файла гарантированно уникально (т.е. вы гарантированно не перезаписываете существующий файл), и файл впоследствии будет удален после уничтожения объекта QTemporaryFile.Это важный метод, позволяющий избежать повреждения данных для приложений, хранящих данные во временных файлах. Имя файла либо автоматически генерируется, либо создается на основе шаблона, который передается конструктору QTemporaryFile.

Пример:

Повторное открытие QTemporaryFile после вызова close () безопасно. Пока сам объект QTemporaryFile не уничтожен, уникальный временный файл будет существовать и будет оставаться открытым внутри QTemporaryFile.

Имя временного файла можно узнать, вызвав fileName ().Обратите внимание, что это определяется только после первого открытия файла; перед этим функция возвращает пустую строку.

Временный файл будет иметь некоторую статическую часть имени и некоторую часть, которая считается уникальной. Имя файла по умолчанию будет определено из QCoreApplication :: applicationName () (иначе qt_temp ) и будет помещено во временный путь, возвращенный QDir :: tempPath (). Если вы укажете собственное имя файла, относительный путь к файлу по умолчанию не будет помещен во временный каталог, а будет относиться к текущему рабочему каталогу.

Указанные имена файлов могут содержать следующий шаблон XXXXXX (шесть символов «X» в верхнем регистре), который будет заменен автоматически сгенерированной частью имени файла. Обратите внимание, что в шаблоне учитывается регистр. Если шаблон отсутствует в имени файла, QTemporaryFile добавляет сгенерированную часть к данному имени файла.

Примечание: В Linux QTemporaryFile попытается создать безымянные временные файлы. Если это удастся, open () вернет true, а exists () будет false.Если вы вызываете fileName () или любую вызывающую его функцию, QTemporaryFile даст файлу имя, поэтому большинство приложений не заметят разницы.

Документация по функциям-членам

QTemporaryFile :: QTemporaryFile (const QString &

Создает QTemporaryFile с именем файла шаблона templateName и указанным родительским элементом . После открытия временного файла он будет использован для создания уникального имени файла.

Если templateName не содержит XXXXXX, он будет автоматически добавлен и использован как динамическая часть имени файла.

Если имя_шаблона - относительный путь, путь будет относиться к текущему рабочему каталогу. Вы можете использовать QDir :: tempPath () для создания templateName , если вы хотите использовать временный каталог системы.

См. Также open () и fileTemplate ().

QTemporaryFile :: QTemporaryFile (QObject *

Создает QTemporaryFile (с заданным родительским файлом ), используя в качестве шаблона файла имя приложения, возвращаемое QCoreApplication :: applicationName () (в противном случае qt_temp ), за которым следует ".XXXXXX ". Файл хранится во временном каталоге системы QDir :: tempPath ().

См. Также setFileTemplate ().

QTemporaryFile :: QTemporaryFile (const QString &

Создает QTemporaryFile с именем файла шаблона имя_шаблона . После открытия временного файла он будет использован для создания уникального имени файла.

Если templateName не содержит XXXXXX, он будет автоматически добавлен и использован как динамическая часть имени файла.

Если имя_шаблона - относительный путь, путь будет относиться к текущему рабочему каталогу. Вы можете использовать QDir :: tempPath () для создания templateName , если вы хотите использовать временный каталог системы.

См. Также open () и fileTemplate ().

QTemporaryFile :: QTemporaryFile ()

Создает QTemporaryFile, используя в качестве шаблона файла имя приложения, возвращаемое QCoreApplication :: applicationName () (иначе qt_temp ), за которым следует ".XXXXXX ". Файл хранится во временном каталоге системы QDir :: tempPath ().

См. Также setFileTemplate () и QDir :: tempPath ().

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

См. Также autoRemove ().

bool QTemporaryFile :: autoRemove () const

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

Автоудаление включено по умолчанию.

См. Также setAutoRemove () и remove ().

Если файл еще не является собственным файлом, то QTemporaryFile создается в QDir :: tempPath (), содержимое файла копируется в него, и возвращается указатель на временный файл.Ничего не делает и возвращает 0 , если файл уже является собственным файлом.

Например:

См. Также QFileInfo :: isNativePath ().

Это перегруженная функция.

Работает с заданным fileName , а не с существующим объектом QFile.

Переопределения: QFile :: fileName () const.

Возвращает полное уникальное имя файла, поддерживающее объект QTemporaryFile. Эта строка имеет значение NULL до открытия QTemporaryFile, после этого она будет содержать fileTemplate () плюс дополнительные символы, чтобы сделать ее уникальной.

См. Также fileTemplate ().

QString QTemporaryFile :: fileTemplate () const

Возвращает установленный шаблон файла. Шаблон файла по умолчанию будет называться qcoreappname.XXXXXX и помещаться в QDir :: tempPath ().

См. Также setFileTemplate ().

bool QTemporaryFile :: open ()

QTemporaryFile всегда будет открыт в режиме QIODevice :: ReadWrite, это обеспечивает легкий доступ к данным в файле. Эта функция вернет истину в случае успеха и установит для fileName () уникальное имя используемого файла.

См. Также fileName ().

Переопределения: QFile :: open (режим QIODevice :: OpenMode).

Создает уникальное имя временного файла и открывает его. Позже вы можете получить уникальное имя, вызвав fileName (). Гарантируется, что файл был создан этой функцией (т.е. он никогда не существовал раньше).

void QTemporaryFile :: setAutoRemove (bool

Устанавливает QTemporaryFile в режим автоматического удаления, если b имеет значение true .

Автоудаление включено по умолчанию.

Если вы установите для этого свойства значение false , убедитесь, что приложение предоставляет способ удаления файла, когда он больше не нужен, включая передачу ответственности другому процессу.Всегда используйте функцию fileName () для получения имени и никогда не пытайтесь угадать имя, которое сгенерировал QTemporaryFile.

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

См. Также autoRemove () и remove ().

void QTemporaryFile :: setFileTemplate (const QString &

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

Если имя содержит относительный путь к файлу, путь будет относиться к текущему рабочему каталогу. Вы можете использовать QDir :: tempPath () для создания name , если вы хотите использовать временный каталог системы.

См. Также fileTemplate ().

Запуск внешних программ в PyQt5 с помощью QProcess, с потоками и индикаторами выполнения

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

В этом руководстве мы рассмотрим QProcess , систему Qt для запуска внешних программ из вашего собственного приложения.

Внешняя программа

Чтобы иметь возможность тестировать запуск внешних программ с помощью QProcess , нам нужно что-то запустить. Здесь мы создадим для этой цели простой скрипт Python, который затем можно будет запустить из нашего приложения.Поместите следующее в файл и сохраните его с именем dummy_script.py .

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

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

  импорт систем
время импорта


def flush_then_wait ():
    sys.stdout.flush ()
    sys.stderr.flush ()
    time.sleep (0,5)


sys.stdout.write ("Стандартный вывод сценария 1 \ n")
sys.stdout.write ("Стандартный вывод сценария 2 \ n")
sys.stdout.write ("Стандартный вывод сценария 3 \ n")
sys.stderr.write ("Общее время: 00: 05: 00 \ n")
sys.stderr.write ("Всего выполнено: 10% \ n")
flush_then_wait ()

sys.stdout.write ("name = Мартин \ n")
sys.stdout.write ("Стандартный вывод сценария 4 \ n")
sys.stdout.write ("Сценарий stdout 5 \ n")
sys.stderr.write ("Всего выполнено: 30% \ n")
flush_then_wait ()

sys.stderr.write ("Прошедшее время: 00: 00: 10 \ n")
sys.stderr.write ("Прошедшее время: 00: 00: 50 \ n")
sys.stderr.write ("Всего выполнено: 50% \ n")
sys.stdout.write ("страна = Нидерланды \ n")
flush_then_wait ()

sys.stderr.write ("Прошедшее время: 00: 01: 10 \ n")
sys.stderr.write ("Всего выполнено: 100% \ n")
sys.stdout.write ("Стандартный вывод сценария 6 \ n")
sys.stdout.write ("Стандартный вывод сценария 7 \ n")
sys.stdout.write ("сайт = www.mfitzp.com \ n")
flush_then_wait ()

  

  из импорта PyQt5.QtWidgets (QApplication, QMainWindow, QPushButton, QPlainTextEdit,
                                QVBoxLayout, QWidget)
из PyQt5.QtCore import QProcess
import sys


класс MainWindow (QMainWindow):

    def __init __ (сам):
        супер () .__ init __ ()

        self.btn = QPushButton ("Выполнить")
        self.btn.pressed.connect (self.start_process)
        self.text = QPlainTextEdit ()
        self.text.setReadOnly (Истина)

        l = QVBoxLayout ()
        l.addWidget (self.btn)
        l.addWidget (самотекст)

        w = QWidget ()
        w.setLayout (l)

        self.setCentralWidget (w)

    def start_process (сам):
        # Здесь мы запустим наш процесс.проходить

app = QApplication (sys.argv)

w = MainWindow ()
w.show ()

app.exec_ ()
  

  p = QProcess ()
p.start ("<программа>", [<аргументы>])
  

  p = QProcess ()
п.start ("python3", ['dummy_script.py'])
  

  p = QProcess ()
p.start ("ffprobe", ['-show_format', '-show_streams', 'a.mp4.py'])
  

  из импорта PyQt5.QtWidgets (QApplication, QMainWindow, QPushButton, QPlainTextEdit,
                                QVBoxLayout, QWidget)
из PyQt5.QtCore импорт QProcess
import sys


класс MainWindow (QMainWindow):

    def __init __ (сам):
        супер().__в этом__()

        self.btn = QPushButton ("Выполнить")
        self.btn.pressed.connect (self.start_process)
        self.text = QPlainTextEdit ()
        self.text.setReadOnly (Истина)

        l = QVBoxLayout ()
        l.addWidget (self.btn)
        l.addWidget (самотекст)

        w = QWidget ()
        w.setLayout (l)

        self.setCentralWidget (w)

    сообщение def (self, s):
        self.text.appendPlainText (s)

    def start_process (сам):
        self.message («Процесс выполнения.»)
        self.p = QProcess () # Сохранять ссылку на QProcess (например,грамм. на себя) во время работы.
        self.p.start ("python3", ['dummy_script.py'])


app = QApplication (sys.argv)

w = MainWindow ()
w.show ()

app.exec_ ()
  

  QProcess: уничтожено, пока процесс ("python3") все еще выполняется.
  

  из импорта PyQt5.QtWidgets (QApplication, QMainWindow, QPushButton, QPlainTextEdit,
                                QVBoxLayout, QWidget)
из PyQt5.QtCore импорт QProcess
import sys


класс MainWindow (QMainWindow):

    def __init __ (сам):
        супер().__в этом__()

        self.p = None # Пустое значение по умолчанию.

        self.btn = QPushButton ("Выполнить")
        self.btn.pressed.connect (self.start_process)
        self.text = QPlainTextEdit ()
        self.text.setReadOnly (Истина)

        l = QVBoxLayout ()
        l.addWidget (self.btn)
        l.addWidget (самотекст)

        w = QWidget ()
        w.setLayout (l)

        self.setCentralWidget (w)

    сообщение def (self, s):
        self.text.appendPlainText (s)

    def start_process (сам):
        если сам.p равно None: # Ни один процесс не запущен.
            self.message («Процесс выполнения»)
            self.p = QProcess () # Сохранять ссылку на QProcess (например, на себя) во время его работы.
            self.p.finished.connect (self.process_finished) # Очистить после завершения.
            self.p.start ("python3", ['dummy_script.py'])

    def process_finished (сам):
        self.message («Процесс завершен.»)
        self.p = Нет


app = QApplication (sys.argv)

w = MainWindow ()
w.show ()

app.exec_ ()
  

  p = QProcess ()
p.readyReadStandardOutput.connect (self.handle_stdout)
p.readyReadStandardError.connect (self.handle_stderr)
p.stateChanged.connect (self.handle_state)
p.finished.connect (самоочистка)
p.start ("питон", ["dummy_script.py"])
  

  из импорта PyQt5.QtWidgets (QApplication, QMainWindow, QPushButton, QPlainTextEdit,
                                QVBoxLayout, QWidget)
из PyQt5.QtCore импорт QProcess
import sys


класс MainWindow (QMainWindow):

    def __init __ (сам):
        супер () .__ init __ ()

        self.p = Нет

        себя.btn = QPushButton ("Выполнить")
        self.btn.pressed.connect (self.start_process)
        self.text = QPlainTextEdit ()
        self.text.setReadOnly (Истина)

        l = QVBoxLayout ()
        l.addWidget (self.btn)
        l.addWidget (самотекст)

        w = QWidget ()
        w.setLayout (l)

        self.setCentralWidget (w)

    сообщение def (self, s):
        self.text.appendPlainText (s)

    def start_process (сам):
        если self.p равен None: # Процесс не запущен.
            self.message («Процесс выполнения»)
            себя.p = QProcess () # Сохранять ссылку на QProcess (например, на себя) во время его работы.
            self.p.readyReadStandardOutput.connect (self.handle_stdout)
            self.p.readyReadStandardError.connect (self.handle_stderr)
            self.p.stateChanged.connect (self.handle_state)
            self.p.finished.connect (self.process_finished) # Очистить после завершения.
            self.p.start ("python3", ['dummy_script.py'])

    def handle_stderr (сам):
        data = self.p.readAllStandardError ()
        stderr = байты (данные).декодировать ("utf8")
        self.message (stderr)

    def handle_stdout (сам):
        data = self.p.readAllStandardOutput ()
        stdout = байты (данные) .decode ("utf8")
        self.message (стандартный вывод)

    def handle_state (себя, состояние):
        состояния = {
            QProcess.NotRunning: 'Не работает',
            QProcess.Starting: 'Запуск',
            QProcess.Running: 'Выполняется',
        }
        state_name = состояния [состояние]
        self.message (f "Состояние изменено: {state_name}")

    def process_finished (сам):
        себя.сообщение ("Процесс завершен.")
        self.p = Нет


app = QApplication (sys.argv)

w = MainWindow ()
w.show ()

app.exec_ ()
  

  data = self.p.readAllStandardError ()
        stderr = байты (данные) .decode ("utf8")
        self.message (stderr)
  

  из PyQt5.Импорт QtWidgets (QApplication, QMainWindow, QPushButton, QPlainTextEdit,
                                QVBoxLayout, QWidget, QProgressBar)
из PyQt5.QtCore импорт QProcess
import sys
импорт ре

# Регулярное выражение для извлечения% завершения.
progress_re = re.compile ("Всего выполнено: (\ d +)%")

def simple_percent_parser (вывод):
    "" "
    Соответствует строкам с использованием регулярного выражения progress_re,
    возвращает одно целое число для% прогресса.
    "" "
    m = progress_re.search (вывод)
    если М:
        pc_complete = м.группа 1)
        вернуть int (pc_complete)


класс MainWindow (QMainWindow):

    def __init __ (сам):
        супер () .__ init __ ()

        self.p = Нет

        self.btn = QPushButton ("Выполнить")
        self.btn.pressed.connect (self.start_process)
        self.text = QPlainTextEdit ()
        self.text.setReadOnly (Истина)

        self.progress = QProgressBar ()
        self.progress.setRange (0, 100)

        l = QVBoxLayout ()
        l.addWidget (self.btn)
        l.addWidget (self.progress)
        l.addWidget (self.текст)

        w = QWidget ()
        w.setLayout (l)

        self.setCentralWidget (w)

    сообщение def (self, s):
        self.text.appendPlainText (s)

    def start_process (сам):
        если self.p равен None: # Процесс не запущен.
            self.message («Процесс выполнения»)
            self.p = QProcess () # Сохранять ссылку на QProcess (например, на себя) во время его работы.
            self.p.readyReadStandardOutput.connect (self.handle_stdout)
            self.p.readyReadStandardError.connect (self.handle_stderr)
            self.p.stateChanged.connect (self.handle_state)
            self.p.finished.connect (self.process_finished) # Очистить после завершения.
            self.p.start ("python3", ['dummy_script.py'])

    def handle_stderr (сам):
        data = self.p.readAllStandardError ()
        stderr = байты (данные) .decode ("utf8")
        # Извлечь прогресс, если он есть в данных.
        прогресс = простой_перцент_парсер (stderr)
        если прогресс:
            self.progress.setValue (прогресс)
        себя.сообщение (stderr)

    def handle_stdout (сам):
        data = self.p.readAllStandardOutput ()
        stdout = байты (данные) .decode ("utf8")
        self.message (стандартный вывод)

    def handle_state (себя, состояние):
        состояния = {
            QProcess.NotRunning: 'Не работает',
            QProcess.Starting: 'Запуск',
            QProcess.Running: 'Выполняется',
        }
        state_name = состояния [состояние]
        self.message (f "Состояние изменено: {state_name}")

    def process_finished (сам):
        self.message ("Процесс завершен.")
        self.p = Нет


app = QApplication (sys.argv)

w = MainWindow ()
w.show ()

app.exec_ ()