Комментарии 5
Первая проблема — digits может использоваться не только этим потоком. Модуль simple_thread позволяет обойти эту проблему. Когда мы получаем атрибут, нам возвращается не ссылка на этот атрибут, а его копия. При этом, все действия происходят в контексте основного потока, и нам не надо беспокоиться об одновременном доступе к атрибуту из нескольких потоков.
В CPython такой проблемы нет — благодаря GIL в любой момент времени исполняеться только один поток. То есть можно не особо задумываясь обмениваться данными с стандартными python-объектами посредством атрибутов. Может возникнуть неожиданное поведение с Qt-объектами и это приводит нас к тому что:
Такой код не совсем Qt-friendly. Намного более идиоматичный вариант — сделать свой поток с сигналом textChanged(str) и присоиденить его соответствующему слоту — setText с помощью Qt::QueuedConnection соединения. Кода это особо не прибавит, а читать это потом будет намного легче. Кроме того если возникнет желание можно будет переписать такие потоки на С++.
В CPython такой проблемы нет — благодаря GIL в любой момент времени исполняеться только один поток. То есть можно не особо задумываясь обмениваться данными с стандартными python-объектами посредством атрибутов.
Да, непосредственно проблемы доступа к питоновским типам нет, но нельзя гарантировать атомарности группы операций. Здесь же мы не можем получить доступ к изменяемому объекту и изменить его — списки и словари копируются, а при попытке доступа к другим изменяемым объектам генерируется исключение.
Такой код не совсем Qt-friendly. Намного более идиоматичный вариант — сделать свой поток с сигналом textChanged(str) и присоиденить его соответствующему слоту — setText с помощью Qt::QueuedConnection соединения. Кода это особо не прибавит, а читать это потом будет намного легче.
Здесь, по большому счету, все так и делается, только скрыто от пользователя. Про размер кода и читаемость спорить не буду, просто мне так показалось удобней.
Кроме того если возникнет желание можно будет переписать такие потоки на С++.
Согласен, но у нас на работе гораздо чаще встречается обратная задача.
Получилась очень хрупкая концепция. Настолько, что аж непонятно — как этим пользоваться без опасения наступить на грабли.
Вообще, я старался уменьшить потенциальное количество грабель, но может сделал все наоборот. Если кому-то будет не лень покопаться в коде и найти грабли, заранее благодарю.
Я сомневаюсь, что это имеет смысл использовать для действительно сложного многопоточного кода. Скорее этот модуль для простых случаев, когда нужно что-то выполнить в отдельном потоке, не мешая основному потоку.
Я сомневаюсь, что это имеет смысл использовать для действительно сложного многопоточного кода. Скорее этот модуль для простых случаев, когда нужно что-то выполнить в отдельном потоке, не мешая основному потоку.
О, спасибо, интересно. Сегодня опробую на практике.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PyQt: простая работа с потоками