Синхронное обращение через сигнал слоты и возврат результата расчета после emit

[SASA]

Кстати для меня загадка, зачем тролли сделали эти методы protected 

Потому что нет никакой необходимости усыплять главный поток.

И чтоб нельзя было усыпить поток из вне.

[Denjs]

Сигнал - это способ сообщить всем, что с объектом что-то случилось. Параметры - подробности случившегося. Этот сигнал могут принять любое (включая ноль) количество заинтересованных.

мой класс дает направление уникального нового способа получить сразу кучу разных результатов при попытке обратиться к обшественности.
типа "кто тут?" и тебе в ответ хох голосов.. ну класно же)

мульти вызов функции))) позволяет например одним сигнлом промониторить состояние десятка обхектов - надо только переписать методо setResult() таким образом что бы он добавлял новое значение в массив. ))))
согласитесь - наступать на грабли одновременно и неизвестно с кем - веселее)

[Igors]

Ладно, поругаем  

1) Какие преимущества по сравнению с BlockingConnection? Вижу одно: можно отвалиться по таймауту - ну значит на это надо упирать (подчеркивать) в описании ф-циональности. И вопрос: а что делать с эти объектом

Код:

 t_returnSyncObject *syncResultObject=new t_returnSyncObject(this);

если отвалились? Нет никакой гарантии что слот не проснется и этот момент непредсказуем. Бодрое

return -1;

есть утечка, нужно зачищать с блокировками.

2)

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

Ну так уж и ничего?    Как минимум оба знают t_returnSyncObject. Возможности взаимодействия определяются тем что умеет/понимает этот (интерфейсный) класс. Потребуется больше параметров - и придется доливать т.к. одним QVariant уже не обойтись (ну или раздувать QVariant что по сути то же). Я против этого ничего не имею, но не вижу что тут нового/выгодного.

[navrocky]

Кстати для меня загадка, зачем тролли сделали эти методы protected 

Потому что нет никакой необходимости усыплять главный поток.

И чтоб нельзя было усыпить поток из вне.

Ну иногда все-таки надо усыплять главный поток, не все же гуёвые приложения.. А во вторых усыпить поток извне этими функциями не возможно.

[BRE]

Ну иногда все-таки надо усыплять главный поток, не все же гуёвые приложения..

Это для чего например? Что бы приложение выполнялось по дольше?

[navrocky]

Ну иногда все-таки надо усыплять главный поток, не все же гуёвые приложения..

Это для чего например? Что бы приложение выполнялось по дольше?

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

[BRE]

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

Ну как бы подобные вещи принято делать в отдельных потоках и пусть они там себе ждут, если надо.
А вот для чего останавливать главный поток?

[SASA]

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

Тролтех подумал об этом void QTest::qSleep ( int ms )

[Igors]

А вот для чего останавливать главный поток?

Да его только и делают что усыпляют  Чем занимается главная нитка - ждет событий (на том же мутексе/семафоре), то же "усыпление".

Что касается sleep (в любой форме), то сколько раз я его ставил - столько же и убирал. Упирается в то что глупо ждать когда ответ уже есть. Так что sleep - для тестовых/отладочных целей, не более. Другое дело - напр ждать на семафоре заданное время, такая возможность есть.

[Denjs]

Что касается sleep (в любой форме), то сколько раз я его ставил - столько же и убирал. Упирается в то что глупо ждать когда ответ уже есть. Так что sleep - для тестовых/отладочных целей, не более. Другое дело - напр ждать на семафоре заданное время, такая возможность есть.

Sleep удобен когда работаешь с оборуоваием и реализуешь в одной процедуре некий протокол обмена данными.

Мол авторизация, 5 сек ждем ответа, команда, ждем ответа, выключиться, ждем статуса завершения.
Если описанное выше делать в асинхронной сигнал слотовой модели - мне нужно делать машину состояний с 4 состояниями, писать 3 процедуры и кучу проверок. И городить ещё и таймер , что бы отслеживать таймаут.

Со слипом это прекрасно уложится в одну функцию. Короткую, простую, понятную.

[navrocky]

Со слипом это прекрасно уложится в одну функцию. Короткую, простую, понятную.

Плюсую.
 
Что бы тут не говорили иногда sleep нужен, и тролли лучше бы сделали одну нормальную реализацию, чем плодили бы их в каждом модуле отдельно.. ну бог им судья. Я лично пользую sleep из буста...

[BRE]

Да его только и делают что усыпляют  Чем занимается главная нитка - ждет событий (на том же мутексе/семафоре), то же "усыпление".

Мы говорим конкретно про sleep в главном потоке, судя по следующему тексту ты это понял, для чего это "пояснение" про мютексы/семафоры? Или это не мне "пояснение" или ты думаешь я этого не знаю?

Упирается в то что глупо ждать когда ответ уже есть.

Золотые слова.

[BRE]

Мол авторизация, 5 сек ждем ответа, команда, ждем ответа, выключиться, ждем статуса завершения.
Если описанное выше делать в асинхронной сигнал слотовой модели - мне нужно делать машину состояний с 4 состояниями, писать 3 процедуры и кучу проверок. И городить ещё и таймер , что бы отслеживать таймаут.

Для чего это делать в главном потоке? Запусти нитку и пусть она хоть по десять минут ждет ответа.

[Igors]

Если не надо отслеживать cancel и перерисовывать окна (а за 5 сек это может понадобиться) - ну тогда конечно sleep всем хорош  Ну да бог с ним, мы отвлеклись.

А вот как удалять созданный экземпляр t_returnSyncObject ? Я поприкидывал, но не вижу простого решения - сложновато получается. Какие есть мнения?

[Denjs]

Для чего это делать в главном потоке? Запусти нитку и пусть она хоть по десять минут ждет ответа.

А,... ну если так... )) но тут скорее вопрос не в главном потоке или нет, а в том, что как "заснуть" в методе класса?
т.е. у меня есть класс - я его засунул в параллельный поток. Потом срабатывает слот - и в этом слоте(слоту?)) мне надо сделать "описанный выше протокол". Я могу получить поток, в котором я сейчас нахожусь - но мне это ничего не даст. т.к. метод "поспать" у обычного QT-шного потока - частный. Приходится или извращаться, или делать кроссплатформенную обертку над ос-зависимыми функциями.

Вспомните - с чего данная нить разговора началась?)