2. Смотря какой цикл и тип соединения сигнала-слота . Если используется DirectConnection, то слот будет выполняться в контексте главного потока и ему будет пофиг что делает доп. поток, а, если QueuedConnection (BlockingQueuedConnection), то чтобы слот вызвался, в доп. потоке должен крутиться QEvenLoop.

была такая мысль..... а что если мне после удаления b понадобится попользоваться ещё a?? ведь после delete b a похерится...как быть в таком случае...

vector <A> mDataVec;
....
vector <A *> ptrVec;
...
ptrVec.clear();
for (int i = 0; i < mDataVec.size(); ++i)
 ptrVec.push_back(&mDataVec[i]);

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

А топологическая сортировка точек не поможет в этом случае?

Ну тогда запускай вначале свой сервер в не оптимальном режиме и на первом этапе формируй базу статистики нагрузки, то есть, как бы обучаешь сервер. После скажем часа работы можно начинать перераспределять задания с учётом накопленных измерений.
То есть если ты такое сделаешь, то мы получим первый в мире потоковый сервер с искусственным интеллектом и способностью обучатся

P.S. Можно даже сказать с применением нано-технологий...

и положил в пул задач. Пул поручает эту работу первой простаивающей нитке.

Это, в принципе, уже было предложено Igors. см. мой ответ http://www.prog.org.ru/index.php?topic=12552.msg79842#msg79842
Но это так, чисто академически. А вообще, основная засада тут в том, что рабочие потоки - асинхронны, т.е. принимают не задачи в виде данных, которые можно обработать и забыть, а в виде QObject-ов, которые крутятся в их цикле событий. Причем нагрузка от этих объектов принципиально непредсказуема - у одного может быть единственный обработчик сообщений, а у другого - полста сигналов и слотов на QueuedConnection. Поэтому поток не может принимать решение о том, что пора взять еще один объект на обработку, основываясь на количестве обслуживаемых объектов. Вот я и пытаюсь выделить критерий, чтобы понять, насколько загружен Event Loop потока.

Знаю, подобная тема поднималась, но ответа на мой вопрос там нет, потому спрошу еще раз... как проверить существует ли переменная.

Пишу такой код:

и в результате ничего не получаю. Может я что-то недопонимаю? а макрос NULL почему-то qt не кушает, выдает ошибку ((

Проблема в том, что задача асинхронная. Т.е. объекты в нитке управляются событиями, приходящими извне. Можно, конечно, выделить очередь событий в отдельную нитку, с которой рабочие потоки будут разбирать задания строго по одному (тут появляется оверхед с сериализацией доступа: получить мьютекс - это довольно дорогая операция в контексте мелких задач на полста умножений). Но в этом случае опять же встает проблема масштабируемости для потока, управляющего очередью заданий - что делать, если очередь событий в нем забилась окончательно, и задание в разы дольше дожидается "постановки на учет", чем собственно обрабатывается? Понятно, надо создать еще одну нитку с параллельной очередью заданий, и добавлять задания в ту, в которой их меньше. Вопрос в том, как узнать, что очередь событий потока заполнилась, и добавлять туда новые неэффективно? Понятно, я ищу сферического коня в вакууме, этакую идеальную парадигму масштабирования, но ведь Генри Форд нам завещал всегда желать большего.

Пока я придумал вот что - в EventLoop'е потока фронтэнда создаю таймер, который постит кастомные события с таймстампом самому себе через равные промежутки времени. Обработчик эти события отлавливает, замеряет время, которое событие простояло в очереди, усредняет/сглаживает его и пишет в член объекта потока. Это получается такая усредненная занятость. Пул менеджер потоки сортирует по этому значению, и по запросу выдает ссылку на поток с наименьшим значением, upd: ну, да, и если потока со значением меньше критического нету, создает новый и выдает ссылку на него. По-моему, довольно кривенько, и оверхед присутствует (вроде небольшой, хотя кто знает), но альтернативы пока не вижу. Пожалуйста, советуйте.

при клике мыши по разным элементам таблицы,срабатывают оба сигнала,что не удивительно )))
Можно ли как-нить сделать так,чтобы сигнал click() срабатывал бы только когда сликаешь по одному и тому же элементу,т.е. когда не срабатывает сигнал selectionChanged(). А в остальных бы случаях срабатывал бы только selectionChanged()

void selectionChanged( ...) 
{
  mSelectionChangedFlag = true;   // запоминаем что пришел сигнал selectionChanged
  ....
}

void click(... )
{
  bool theSelectionChangedFlag = mSelectionChangedFlag;   // копируем флаг 
  mSelectionChangedFlag = false;                                     // зачищаем для след. сеанса
  ...
  if (!theSelectionChangedFlag) {
    .... // ага, это "новая" ячейка, прпопускаем
  }
  else {
    .... // click на уже выбранную - акция
}

Сталкивался ли кто-нибудь??? Особенно проблема 2 интересует!