Вопрос

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

Используемый IPC — это очереди сообщений Unix.

Данные должны обновляться через определенный интервал, скажем, 3 секунды.

Теперь проблема, с которой я столкнулся, заключается в том, что обработка данных, которые должны быть показаны, занимает более 3 секунд, поэтому я сделал следующее: прежде чем приложение начнет обрабатывать данные для следующего обновления, обновление QTimer останавливается. и после обработки данных я снова перезапускаю QTimer. Приложение должно работать таким образом, чтобы после обновления/обновления (во время этого обновления приложение перестает отвечать на запросы) у пользователя должно быть достаточно времени, чтобы продолжить работу над приложением, кроме видя, как обновляются данные. Я могу получить приемлемые паузы для работы пользователя - в одном сценарии.

Но в разных ОС (от RHEL 5.0 до RHEL 5.2) ситуация иная. Таймер сходит с ума и продолжает срабатывать без каких-либо пауз между последовательными обновлениями, таким образом переходя в бесконечный цикл. Обработка этих данных обновления определенно занимает больше времени, чем 3 секунды, но именно по этой причине я остановил-перезапустил таймер во время обработки... и та же логика работает в одном сценарии, а в другом - нет.Другой факт, который я заметил, заключается в том, что когда происходит это быстрое срабатывание таймера, время, необходимое функции обновления для выхода, очень мало, около 300 мс, поэтому старт-стоп таймера, который я поместил в начало и конец Эта функция происходит за это короткое время... поэтому до того, как фактическая обработка данных завершится, в очереди есть 3-4 запуска таймера, ожидающих выполнения, и, таким образом, проблема бесконечного цикла с этого момента ухудшается при каждом последующем обновлении. .

Здесь важно отметить, что для одного и того же кода в одной ОС время обновления составляет около 4000 мс (фактическое время обработки того же объема данных), а для другой ОС — 300 мс.

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

Итак, мой вопрос заключается в том, есть ли какой-либо способ гарантировать, что некоторая обработка в моем приложении будет выполняться по времени (и независимо от ОС) без использования QTimer, поскольку я думаю, что QTimer не является хорошим вариантом для достижения того, чего я хочу??

Какой тут может быть вариант??pthreads или Boost threads?какой из них был бы лучше, если бы я использовал потоки в качестве альтернативы?? Но как я могу обеспечить по крайней мере трехсекундный интервал между последовательными обновлениями, независимо от того, сколько времени занимает обработка обновлений?

Пожалуйста, помогите.

Спасибо.

Это было полезно?

Решение

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top