Тут есть один нюанс, дело в том, что Windows не система реального времени. А это значит, что посылаете вы допустим с устройства 18 байт. В COM-порт он попадают побайтно, сама система их может выдать сразу 18, или сначала 10, потом 8. Или сначала 12, потом 6.
Что мы получим в этом случае, принимаем сигнал readyRead, вызываем readAll и получаем 12 байт вместо 18. Потому что в момент прихода сигнала в буфер успело попасть только 12 байт, еще 6 придут чуть позже. Проверено не единожды с использованием разных контроллеров и программы AdvansedSerialPort, запущенной в режиме сниффера.
Я не совсем уверен что в данном случае есть прямая зависимость от логики в гуёвом потоке и стабильностью работы. Может приведете пример, что мне надо изменить, чтобы программа упала?
Спасибо за статью, как-то прошла мимо меня, но в ней опять же не раскрывается тема, почему наследование от QThread — это плохо и к чему оно может привести.
Было бы интересно уточнить именно этот момент, чтоб окончательно поставить все точки на i.
Здесь я склонен с вами не согласится. Есть два подхода, я об этом упомянул в тексте статьи.
Можно помещать объект в поток, используя QObject::moveToThread, а можно наследоваться от QThread.
Сами разработчики-Qt используют их оба в своей документации и примерах.
Я в своей работе использовал и тот и другой подход. У каждого есть свои плюсы и минусы.
Если не сложно, хотелось бы увидеть какие-либо реальные примеры, показывающие, что использование наследования от QThread — это плохо.
А почему он должен подвисать?!
Наиболее времязатратное действие происходит в другом потоке, влияние на GUI быть не должно. Во всяком случае данный подход какого-либо заметного влияния на работу GUI не оказывает.
Я с вами вполне согласен. Тот пример, что привел я, проще реализовать, используя MVC. Когда я брался за свой проект, взвесив все за и против MVC и MVP, выбрал MVP. Реальный проект сложнее, чем то, который приведен в примере, поэтому явно, почему был выбран именно MVP, возможно не видно. Но и цели такой не было, была цель показать подход.
Что мы получим в этом случае, принимаем сигнал readyRead, вызываем readAll и получаем 12 байт вместо 18. Потому что в момент прихода сигнала в буфер успело попасть только 12 байт, еще 6 придут чуть позже. Проверено не единожды с использованием разных контроллеров и программы AdvansedSerialPort, запущенной в режиме сниффера.
Было бы интересно уточнить именно этот момент, чтоб окончательно поставить все точки на i.
Можно помещать объект в поток, используя QObject::moveToThread, а можно наследоваться от QThread.
Сами разработчики-Qt используют их оба в своей документации и примерах.
Я в своей работе использовал и тот и другой подход. У каждого есть свои плюсы и минусы.
Если не сложно, хотелось бы увидеть какие-либо реальные примеры, показывающие, что использование наследования от QThread — это плохо.
Наиболее времязатратное действие происходит в другом потоке, влияние на GUI быть не должно. Во всяком случае данный подход какого-либо заметного влияния на работу GUI не оказывает.