QTcpSocket в QThread

В exec тот самый (не простой) бесконечный цикл, как в играх. Самому класть, это вызывать invokeMethod, а не просить об этом пользователя. :)

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

Но что означит самому? Снова таймер что-ли?

Я снова не понимаю. Если я пошлю бесконечный цикл, то остальным событиям настанет кирдык. Мне нужен и цикл и события одновременно.

Вы кладете в очередь сообщений событие «вызвать метод А» и запускаете цикл обработки событий (тот самый настоящий бесконечный цикл). Когда дело доходит до этого события - вызывается ваш метод А. Вы делаете необходимые действия, кладете в очередь сообщений еще раз событий «вызвать метод А» и выходите. Цикл повторяется: опрашиваются соекты, обрабатываются события и когда дело доходит до вызова А - все повторяется.

Так бы сразу и объяснили. :) Метод интересный, если хочется распределять ресурсы между программами, так и вообще красивый. Я не внимательно посмотрел пример anonymous-а. Но опять он не всегда самый лучший, в симуляторах и играх делают именно while(true), который использует ресурсы на всю катушку.

Это ровно тоже самое. Qt нужен этот бесконечный цикл для своих нужд: обработка событий, пулинг сокетов, обслуживание таймеров... Поэтому, лучше использовать именно его, раз он уже есть, а свой код дергать их него. Кстати, таймер с нулевым интервалом, так же прикрасно с этим справляется - будет вызываться каждую итерацию.

Ну если все равно, то тогда чем dispatcher->processEvents(QEventLoop::AllEvents) хуже? Нет, мне конечно события больше нравятся именно с архитектурной стороны, но все же. while(true) все-таки думаю немного другое. Одно дело крутить обработку в цикле, лазить в очередь и тут же опять же продолжать работу, так как ничего в ней нет и другое дело постоянно класть в очередь и вынимать из нее. И локальными переменными не шибко попользуешься между вызовами. Кстати попутный вопрос, ничего более нормального чем invokeMethod(this,«string») нету? Вызов по имени это же ахтунг. Сигналы конечно тоже не хочется использовать.

На самом деле все равнозначно (ну кроме локальных переменных) и каждый подход можно переделать в другой. А вместо invoke можно задействовать таймер с нулевым интервалом. Он будет срабатывать каждую итерацию бесконечного цикла.

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

Что за предубеждения? :)

Один раз настроили таймер и он будет каждую итерацию дергать указанный вами метод, в котором вы будете делать то, что собирались делать в своем бесконечном цикле.

Можно сделать так. Коннектишь сигнал о приходе данных от TCP клиента к слоту. Вызываешь exec(). Сигнал приходит и вызывается слот. В слоте читаешь эти данные и делаешь quit(N).

Как-то так (у меня sslsocket):

void Thread::run()
{
    QSslSocket socket;
    ...
    connect(&socket, SIGNAL(bytesAvailable..., SLOT(slotBytes()));

    while(true)
    {
      switch(exec())
      {
          case 1:
              buffer = socket.readAll();
          break;
      }
    }
}

void Thread::slotBytes()
{
    quit(1);
}

Можно коннектить не к слоту, а сразу к quit(), если кроме прихода данных тебе никаких сигналов не нужно. Кривовато, но что поделаешь.

Ладно, может попробую, интересно все таки. :) Но вопрос про invokeMethod(this,«string») немного шире. Не буду же я создавать таймер каждый когда хочу послать событие. :) Можно конечно забабахать функцию в которую буду передавать указатель на функцию и уже она будет создавать таймер, но архитектурно это выглядит очень чудно.

Забавно, а как оно по производительности?

Это все тоже, только вид сбоку. По производительности также, как и обычный бесконечный цикл. :)

у меня поток данных не такой толстый, несколько сотен Kb/s. Проблем нет, да и не вижу откуда им взяться. Тут оверхед минимальный.