|
|
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
Какие у нас есть варианты? - Система слот/сигнал в таком варианте работает потокобезопасно и асинхронно. - QApplication::postEvent(). Ещё варианты есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2020, 18:25 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petrav Ещё варианты есть? И кстати, система сигналов сама использует postEvent() внутри. А оно использует QQueue... Так что можешь еще вручную с очередями играться. Но если сильно хочется... Тогда отходи от Qt стандартов и делай ну например разделяемую память. Или очереди-сигналы на основе pthereads. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2020, 19:19 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2020, 19:22 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
White Owl petrav Ещё варианты есть? И кстати, система сигналов сама использует postEvent() внутри. А оно использует QQueue... Так что можешь еще вручную с очередями играться. Я ради интереса спросил. Да и обсудить. В данном случае мне не нравятся слоты/сигналы, потому что придётся активировать кодогенератор (Q_OBJECT) там где он не нужен. Я, пожалуй, напишу вокруг postEvent() простую обёртку принимающую функтор (std::function + std::bind). Что бы одним движением вызывать методы классов из потока GUI. Я подумал может там (в Qt) что-то готовое в таком духе есть. White Owl Но если сильно хочется... Тогда отходи от Qt стандартов и делай ну например разделяемую память. Или очереди-сигналы на основе pthereads. Да чёта... Ну. С трудом себе представляю как это интегрировать с очередью событий в Qt. Наверное, это излишне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2020, 20:48 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
Там выше небольшая ошибка, правка: Что бы одним движением вызывать методы классов в потоке GUI. Вот тоже интересно, если поток создан с помощью std::thread, а мы из него вызовем сигнал, а слот подключён к объекту Qt принадлежащему потоку GUI? Т.е. вот корректно ли ожидать рабочего симбиоза от разных... инструментов многопоточности (QThread, std::thread)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2020, 21:06 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petrav Вот тоже интересно, если поток создан с помощью std::thread, а мы из него вызовем сигнал, а слот подключён к объекту Qt принадлежащему потоку GUI? Т.е. вот корректно ли ожидать рабочего симбиоза от разных... инструментов многопоточности (QThread, std::thread)? Хочешь устойчивой работы в Qt - забудь про std. Не нужно оно. Вообще. Все что предоставляет std - уже есть в Qt. Вообще, рекомендую забыть что Qt это С++. Qt это отдельный язык основанный на C++, но это не С++. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 01:39 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petrav, >Я, пожалуй, напишу вокруг postEvent() простую обёртку принимающую функтор (std::function + std::bind = для себя пиши. Для работодателя и других прогеров нет. Тебя никто не поймет. Прикладник должен любить пользоваться публичными либами, платформами и концепциями. В данном случае Qt. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 07:47 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petrav, >Что бы одним движением вызывать методы классов в потоке GUI. = на самом деле, в приложении не нужно делать кучу мест на потоках, из котрых нужно "одним движением". Большинство задачек можно успеть вычислить на ButtonsClick(). Если нет, то что то с архитектурой. Или подготовленными промежуточными вычислениями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 07:53 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 11:55 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petrav, Смотрите шире. Каждый класс наследник QObject уже имеет таймер. Встроенный + QTimerEvent будет достаточно для ваших задач. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 12:16 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
Про потоки из справки: В многопоточных приложениях вы можете использовать QTimer в любом потоке, имеющем цикл событий. Чтобы запустить цикл обработки событий из потока без графического интерфейса, используйте QThread :: exec (). Qt использует привязку потока таймера, чтобы определить, какой поток испускает сигнал timeout () . Из-за этого вы должны запускать и останавливать таймер в его потоке; невозможно запустить таймер из другого потока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 12:23 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
PetroNotC Sharp petrav, Смотрите шире. Каждый класс наследник QObject уже имеет таймер. Встроенный + QTimerEvent будет достаточно для ваших задач. Кстати да, про поток с очередью событий я не подумал. Вопрос, конечно, в точности такого таймера. Но в любом случае, концепция о полной несовместимости Qt, C++ и WinAPI мне кажется странной. Такое положение вещей означало бы смерть и std, и Qt. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 12:58 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petrav, - сам Qt для ГУИ где точность не особо нужна. - они не то что несовместимы. Это закон такой - если платформа, то пляши по неё. Она диктует архитектуру. Разрабы ЗА ТЕБЯ все продумали. Это в люом ЯП так. В шарпе при винформ писать надо было так, а при Core по другому. И т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 13:13 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petrav, Насчет очереди события я вижу так: Либо мы стартуем без таймера 10 потоков и они делают работу. По окончании сигнализируют. Либо с таймером стартуем обновление ГУИ, но таймер сам вызовет событие в основном потоке ГУИ. Причем тогда потоки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 13:18 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petravНо в любом случае, концепция о полной несовместимости Qt, C++ и WinAPI мне кажется странной. Такое положение вещей означало бы смерть и std, и Qt. А что в ней странного? Qt писалась под Линух, поэтому с WinAPI оно несовместимо по определению. std делалось как кроссплатформенное, соответственно несовместимо с двумя остальными. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 13:36 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
PetroNotC Sharp petrav, Насчет очереди события я вижу так: Либо мы стартуем без таймера 10 потоков и они делают работу. По окончании сигнализируют. Либо с таймером стартуем обновление ГУИ, но таймер сам вызовет событие в основном потоке ГУИ. Причем тогда потоки? Поток timeSetEvent() обслуживает работу с оборудованием, неограниченное время работы. И желательно в мягком реалтайме. Но поток таймера timeSetEvent() должен влиять и на GUI. Я для этого использую postEvent(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 13:58 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petrav, >Поток timeSetEvent() обслуживает работу с оборудованием, =эту фразу можно заменить более привычными понятиями: "требуется постоянно опрашивать бд на предмет новой инфы". Сколько длится цикл опроса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 14:25 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petravПоток timeSetEvent() обслуживает работу с оборудованием, неограниченное время работы. И желательно в мягком реалтайме. И зачем тогда в нём таймер? Там должен быть QNanoSleep, QWaitFor или что-то в этом роде. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 14:28 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov petravНо в любом случае, концепция о полной несовместимости Qt, C++ и WinAPI мне кажется странной. Такое положение вещей означало бы смерть и std, и Qt. А что в ней странного? Qt писалась под Линух, поэтому с WinAPI оно несовместимо по определению. std делалось как кроссплатформенное, соответственно несовместимо с двумя остальными. Странен сам предполагаемый подход. Представьте себе, что QMutex, вызванный из WinAPI потока, каким-то образом пытается получить указатель на объект QThread связанный с этим потоком. И не найдя этот объект потока начинаются крайне сложно воспроизводимые глюки. Это было бы больше похоже на вредительство внутри команды разработчиков Qt. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 18:45 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
petrav, Какой то выдуманный пример. Не надо мьютекс использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 19:43 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov petravНо в любом случае, концепция о полной несовместимости Qt, C++ и WinAPI мне кажется странной. Такое положение вещей означало бы смерть и std, и Qt. А что в ней странного? Qt писалась под Линух, поэтому с WinAPI оно несовместимо по определению. std делалось как кроссплатформенное, соответственно несовместимо с двумя остальными. Да ну. Что конкретно в Qt несовместимо с std? Вот например https://doc.qt.io/qt-5/containers.html#stl-style-iterators qHash() для std::pair есть. В QVector есть методы fromStdVector, toStdVector. В QMap - toStdMap. Для QString тоже есть toStdString. А, вот еще https://doc.qt.io/qt-5/qtalgorithms.html Historically, Qt used to provide functions which were direct equivalents of many STL algorithmic functions. Starting with Qt 5.0, you are instead encouraged to use directly the implementations available in the STL ; most of the Qt ones have been deprecated (although they are still available to keep the old code compiling). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 21:33 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
Насчет "Qt писалось под linux, и с WinAPI несовместимо" тоже сомнительно. У того же QThread есть например метод setPriority , который работает под windows, а под линуксом ничего не делаетThe effect of the priority parameter is dependent on the operating system's scheduling policy. In particular, the priority will be ignored on systems that do not support thread priorities (such as on Linux, see http://linux.die.net/man/2/sched_setscheduler for more details). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 21:48 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
BarloneУ того же QThread есть например метод setPriority, который работает под windows, а под линуксом ничего не делает А теперь самое главное по ссылке: "This function was introduced in Qt 4.1.", что чертовски далеко от "писалось". Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 22:25 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
Barlone Dimitry Sibiryakov пропущено... А что в ней странного? Qt писалась под Линух, поэтому с WinAPI оно несовместимо по определению. std делалось как кроссплатформенное, соответственно несовместимо с двумя остальными. qHash() для std::pair есть. В QVector есть методы fromStdVector, toStdVector. В QMap - toStdMap. Для QString тоже есть toStdString. Они имеют ввиду "я конечно не экономист, но точно чувствую гнилое здесь дело, лажа какая то зарыта" — как в экранизации Пелевина. В том плане, что в сложных вопросах межпоточного взаимодействия там действительно могут быть проблемы. Хотя допустить такое... ну это нужно как-то осмысленно навредить. Но вот если вспомнить функцию _beginthread(). Дело в том, что ::CreateThread() ничего не знает про CRT и потоки созданные с помощью ::CreateThread() не совсем корректно потом работают с Си-рантаймом. Но тут я что-то подзабыл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2020, 23:16 |
|
||
|
Qt: передача сообщения в поток GUI
|
|||
|---|---|---|---|
|
#18+
Несколько мыслей. 1) Большинство современных UI - по сути однопоточные. Были попытки построить реально мультипоточный UI у Apple (iPhone). Не знаю насколько успешные. Пускай знающие расскажут. 2) Все кросс-платформенные UI фреймворки обычно терпят неудачу при глубоком использовании. Тоесть либо ты не можешь использовать какую-то фичу просто потому что она в Gnome/KDE отсуствует а есть в Windows. Либо для использования фичи ты все равно вынужден ходить в API ОС в обход UI фреймворка. 3) Приходится проект разделять на под-проекты-платформеры Linux/Win/Mac и писать реализации раздельно при некой общей разделяемой части логики. 4) Даже под одну ОС UI может иметь несколько независимых способов программинга (WinGDI, OpenGL, DirectX) и это еще сильнее путает разработчика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2020, 01:01 |
|
||
|
|
start [/forum/topic.php?fid=57&msg=40030761&tid=2017277]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
2ms |
| others: | 17ms |
| total: | 167ms |
| 0 / 0 |
