> там один парень обнаружил, что эти действия, описанные в производном классе, выполняются в том же потоке, где объект производного класса QThread был создан, а не в новом потоке
Это и так понятно. То что находится или вызывается из run выполняется в дочернем потоке, а то что вызывается из основного будут выполнены в основном.
> И из-за этого появляются зависания, так как действия другого потока происходят не в другом потоке, а в этом же потоке - в главном потоке.
Конечно, если не верно проектировать многопоточное приложение, то так и будет.
Rodegastну есть мнение что "Класс QThread создан и предназначен для использования в качестве интерфейса к потокам операционной системы, но не для того, чтобы помещать в него код, предназначенный для выполнения в отдельном потоке. В ООП мы наследуем класс для того чтобы расширить или углубить функциональность базового класса. Единственное оправдание для наследования QThread, которое я могу представить, это добавление такой функциональности, которой в QThread не существует, например, передача указателя на область памяти, которую поток может использовать для своего стека, или, возможно, добавление поддержки интерфейсов реального времени. Загрузка файлов, работа с базами данных, и подобные функции не должны присутствовать в наследуемых классах QThread; они должны реализовываться в других объектах»
Чем же тебе метод run() не нравится?
источник https://www.qt.io/blog/2010/06/17/youre-doing-it-wrong
Т.е. наследование от QThread не то чтобы совсем неправильно, но приводит к ненужному смешиванию разных наборов функций в одном классе, что ухудшает читаемость и поддерживаемость кода.
> Т.е. наследование от QThread не то чтобы совсем неправильно, но приводит к ненужному смешиванию разных наборов функций в одном классе, что ухудшает читаемость и поддерживаемость кода.
Вот что бы этого не происходило нужно следовать принципу “единой ответственности”. Т.е. в наследнике от QThread должен содержаться код который будет работать только в отдельном потоке, а всё остальное должно быть вынесено из этого класса.
Вот что бы этого не происходило нужно следовать принципу “единой ответственности”. Т.е. в наследнике от QThread должен содержаться код который будет работать только в отдельном потоке, а всё остальное должно быть вынесено из этого класса.
Видимо, тут какая-то ошибка архитектуры Qt. В результате появилось два способа порождать потоки и куча разговоров о том, как всё же правильно это делать.
Девчонка эта пишет, что до своей публикации она ничего не нашла в документации по Qt, кроме способа через run(). Остальные пишут, что постоянно сталкиваются со странными проблемами при многопоточной разработке через run(). И тут она выявляет своим умом правильный способ, решающий все проблемы, и публикует его. Тут же все подтверждают, что их проблемы решились этим способом. А дальше откуда-то в документации Qt появляется этот её способ.
И теперь там типа два способа существует, кучи разговоров ведутся и типа так и должно быть.
tags: pyqt thread
Девчонка эта пишет, что до своей публикации она ничего не нашла в документации по Qt, кроме способа через run(). Остальные пишут, что постоянно сталкиваются со странными проблемами при многопоточной разработке через run(). И тут она выявляет своим умом правильный способ, решающий все проблемы, и публикует его. Тут же все подтверждают, что их проблемы решились этим способом. А дальше откуда-то в документации Qt появляется этот её способ.
И теперь там типа два способа существует, кучи разговоров ведутся и типа так и должно быть.
tags: pyqt thread