Вопрос: При вызове слота - он будет работать в отдельном потоке не останавливая цикл for , или же они будут работать последовательно, приостанавливая друг друга ?

приложение написано с использованием минимального кода и никаких QThread мы сюда специаьно руками не добавляем.

Ну ты понел, да?

нет не понЯл

есть всякие фокусы, котоорые сбивают меня с однозначности понимания, например

oid QCoreApplication::processEvents ( QEventLoop::ProcessEventsFlags flags = QEventLoop::AllEvents ) 
qApp->processEvents();

которые позволяют приложению в одном потоке не заставлять ждать, фкус эти крайне не понятны мне.

Мультизадачность и событийная модель - ты знаешь, что это такое?

Зависит от связи сигналов и слотов.
Если связаны напрямую - вызов слота через сигнал равносилен вызову слота как функции непосредственно в коде. Если связаны через очередь сообщений - тогда только по завершению цикла.

P.S. Для просветления читать про пятый параметр в QObject::connect и основной цикл GUI-шных программ.

Все будет работать в потоке, в котором вызван app.exec(), т.е. «они будут работать последовательно, приостанавливая друг друга»

udp. Трекс выше дал правильное уточнение про очередь сообщений.

Мультизадачность == Многозадачность ? событийная модель == основные события в Qt крутят по кругу, друг за другом ?

Обычно при вызове сигнала просто будут вызываться все соединенные слоты в том же потоке. Но, насколько я помню, если connect был сделан в одном потоке, а emit идёт из другого потока, то тогда будет кросспоточный вызов и emit продолжит своё выполнение, а тому потоку пошлётся сообщение и если он его обработает, то в этот момент вызовется метод-слот.

Вообще для понимания того, как это всё работает, рекомендую посмотреть, что творит moc с исходниками, посмотреть результат после работы препроцессора и посмотреть исходники всех интересующих функций в Qt. Мне это прояснило многие моменты, никакой магии там нет, всё на самом деле просто, до этого было недопонимание того, как это работает.

Про потоки выше написали про пятый аргумент, видимо верно, я скорее всего напутал про то, что кросс-поточный вызов идёт, если connect и emit из разных потоков.

http://qt-project.org/doc/qt-4.8/qt.html#ConnectionType-enum

Там очень тупая логика, замаскированая под «ВАУ, сигналы-слоты!».

Короче, если целевой слот в том-же потоке и соединён через BlockingConnection то будет как-бы:

int d=0;
for (int i=0;i<10;++i)
{
    myslot(i);
    d+=i;
}

int d=0;
for (int i=0;i<10;++i)
{
    // поместить вызов слота в очередь EventLoop
    d+=i;
}
// разный другой код
// возврат в EventLoop
myslot(i)
...
// и так 10 раз
// и ещё не факт что между какими-то вызовами mysqlot не вклиниться вызов какого-то другого метода

То есть, используя emit вы в принципе не можете прогнозировать как и когда будет выполнен код. Может быть сейчас, а может быть потом.

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

Бред. Читать документацию до полного просветления. Там ясно сказано в каких случаях слот вызывается напрямую, а в каких — отложенно.

Это не фокус, а просто проверка очереди сообщений. Позволяет приложению обрабатывать сообщения, пока оно занято. Чревато неожиданными эффектами, связанными с рекурсивным заходом в работающую функцию или изменениями данных, с которыми она работает.

Давайте ссылку, чего уж там. Если я ошибаюсь то готов увидеть ошибку.

http://qt-project.org/doc/qt-4.8/qt.html#ConnectionType-enum

http://qt-project.org/doc/qt-4.8/threads-qobject.html

http://qt-project.org/wiki/Threads_Events_QObjects

Всё понял, был неправ, RTFM, пойду читать маны, документацию и прочие источники мудрости...