[Решено] Скорость работы модели слот-сигнал

[titan83]

Здравствуйте.
На ARM9 400Mhz запускаю программу для опроса шины CAN, для чего использую подсистему ядра SocketCAN, она создает сетевой интерфейс, с которым можно работать как с простым сокетом.
Ну я, как простой посан с Урала, делаю простой класс для отлова входящих сообщений на шине, применяя для этих целей в первом заходе QSocketNotifier - и все вроде бы работает, сообщения отлавливаются, но! я отключаю физически кабель шины, а сообщения все поступают и поступают... Видимо имеет место быть буферизация, т.к. через некоторое время поток кадров прекращается.
Грусть-печаль... Ставлю пакет can-utils, в его составе есть candump, запускаю и вижу, что входящий поток довольно быстрый (около 10 кадров в секунду), отключаю провод и прием сразу останавливается, т.е. входящий поток обрабатывается с той скоростью, с которой он поступает.
В qt же я получаю от силы три кадра в секунду - остальное в буфер. Естественно, это крайне неприятно, ибо на сообщения устройства надо реагировать немедленно, а не через минуту.
Попробовал я отказаться от QSocketNotifier - сделал свой poll() - все так же(
Посмотрел код того же candump - там все делается аналогично - открытие порта и потом select(), но там нет оберток qt, неужели все настолько медленно?

[Old]

неужели все настолько медленно?

DirectConnect сводится к обычному прямому вызову метода.

Попробовал я отказаться от QSocketNotifier - сделал свой poll() - все так же(

Т.е. вы сделали свой цикл с select как в candump, а он работает медленней чем в candump? Как то не верится, что проблема в сигналах?

[titan83]

Т.е. вы сделали свой цикл с select как в candump, а он работает медленней чем в candump? Как то не верится, что проблема в сигналах?

Я лишь хочу разобраться в чем именно проблема, ибо в таком виде меня это абсолютно не устраивает.
Я, кстати, делал poll(), а в candump - select(), попробую с ним.

[Old]

Я лишь хочу разобраться в чем именно проблема...

А я хочу вам в этом помочь.
Попробуйте сделать обработку событий как в candump и не посылайте сигнал, а просто печатайте в консоль. Посмотрите на скорость. Потом, добавьте сигналы и проверьте с ними.
Просто, я сильно сомневаюсь, что дело в сигналах. Или вы используете сигналы между потоками?

[GreatSnake]

И не мешало бы проверить как сильно кушается CPU.

[titan83]

А я хочу вам в этом помочь.

Спасибо за участие.
Как обычно - напишешь - поможешь себе сам)

Может кому пригодится - помимо опроса CAN у меня в программе работало еще несколько модулей, и все они базировались на общем классе, выполняющем поллинг файлов на sysfs. И ключевой функцией этого класса была QTimer::singleShot, которая вызывала слот опроса.
Проблема была в том, что у меня в качестве времени отсрочки выполнения слота стояло 0, и еще и таймаут в функции poll() стоял 100 мс, в итоге, как я понимаю, я своими singleShot (от трех-четырех объектов), забивал event loop и остальным слотам оставалось намного меньше процессорного времени.
В качестве решения я поменял отсрочку запуска слота с 0 на 50 мс и уменьшил таймаут poll() со 100 до 50 мс, теперь у меня все живут дружно.

Всем еще раз спасибо.

[xokc]

Как обычно - напишешь - поможешь себе сам)

Не в плане наезда, но: правильно сформулированный вопрос - и есть половина ответа. Так, что тут, действительно всё закономерно. Как и то, что в первую очередь подумали, что виноват "медленный сигнал-слот" .