Russian Qt Forum
Апрель 28, 2024, 12:43 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Russian Qt Forum > Forum > Qt > Кладовая готовых решений (Модератор: Пантер) > Синхронное обращение через сигнал слоты и возврат результата расчета после emit
Страниц: 1 [2] 3   Вниз
« предыдущая тема следующая тема »
  Печать  
Автор Тема: Синхронное обращение через сигнал слоты и возврат результата расчета после emit  (Прочитано 27684 раз)
SASA
Гость
« Ответ #15 : Октябрь 14, 2010, 17:23 »
Цитата: BRE от Октябрь 14, 2010,  17:19
Цитата: navrocky от Октябрь 14, 2010,  12:55
Кстати для меня загадка, зачем тролли сделали эти методы protected  Непонимающий
Потому что нет никакой необходимости усыплять главный поток.


И чтоб нельзя было усыпить поток из вне.
Записан
Denjs
Гость
« Ответ #16 : Октябрь 15, 2010, 00:11 »
Цитата: SASA от Октябрь 14, 2010,  17:20
Сигнал - это способ сообщить всем, что с объектом что-то случилось. Параметры - подробности случившегося. Этот сигнал могут принять любое (включая ноль) количество заинтересованных.
мой класс дает направление уникального нового способа получить сразу кучу разных результатов при попытке обратиться к обшественности.
типа "кто тут?" и тебе в ответ хох голосов.. ну класно же)

мульти вызов функции))) позволяет например одним сигнлом промониторить состояние десятка обхектов - надо только переписать методо setResult() таким образом что бы он добавлял новое значение в массив. ))))
согласитесь - наступать на грабли одновременно и неизвестно с кем - веселее)
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #17 : Октябрь 15, 2010, 01:21 »
Ладно, поругаем  Улыбающийся

1) Какие преимущества по сравнению с BlockingConnection? Вижу одно: можно отвалиться по таймауту - ну значит на это надо упирать (подчеркивать) в описании ф-циональности. И вопрос: а что делать с эти объектом
Код:
 t_returnSyncObject *syncResultObject=new t_returnSyncObject(this);
если отвалились? Нет никакой гарантии что слот не проснется и этот момент непредсказуем. Бодрое
Цитировать
return -1;
есть утечка, нужно зачищать с блокировками.

2)
Цитата: Denjs от Октябрь 13, 2010,  15:48
В каком-то смысле, это "внутрипрограммная" реализация идей SOA - "через сигнал-слот вызывается расчет каких-либо значений, и ни источник ни приемник не знают друг о друге ничего".
Ну так уж и ничего?  Улыбающийся  Как минимум оба знают t_returnSyncObject. Возможности взаимодействия определяются тем что умеет/понимает этот (интерфейсный) класс. Потребуется больше параметров - и придется доливать т.к. одним QVariant уже не обойтись (ну или раздувать QVariant что по сути то же). Я против этого ничего не имею, но не вижу что тут нового/выгодного.
Записан
navrocky
Гипер активный житель
*****
Offline Offline

Сообщений: 817


Погроммист


Просмотр профиля
« Ответ #18 : Октябрь 15, 2010, 09:45 »
Цитата: SASA от Октябрь 14, 2010,  17:23
Цитата: BRE от Октябрь 14, 2010,  17:19
Цитата: navrocky от Октябрь 14, 2010,  12:55
Кстати для меня загадка, зачем тролли сделали эти методы protected  Непонимающий
Потому что нет никакой необходимости усыплять главный поток.


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

Ну иногда все-таки надо усыплять главный поток, не все же гуёвые приложения.. А во вторых усыпить поток извне этими функциями не возможно.
Записан
Гугль в помощь
BRE
Гость
« Ответ #19 : Октябрь 15, 2010, 10:55 »
Цитата: navrocky от Октябрь 15, 2010,  09:45
Ну иногда все-таки надо усыплять главный поток, не все же гуёвые приложения..
Это для чего например? Что бы приложение выполнялось по дольше?
Записан
navrocky
Гипер активный житель
*****
Offline Offline

Сообщений: 817


Погроммист


Просмотр профиля
« Ответ #20 : Октябрь 15, 2010, 11:03 »
Цитата: BRE от Октябрь 15, 2010,  10:55
Цитата: navrocky от Октябрь 15, 2010,  09:45
Ну иногда все-таки надо усыплять главный поток, не все же гуёвые приложения..
Это для чего например? Что бы приложение выполнялось по дольше?


Тесты, работа с оборудованием, всякие специфические задачи, типа запустить программку подождать немного, обратиться...
Записан
Гугль в помощь
BRE
Гость
« Ответ #21 : Октябрь 15, 2010, 11:10 »
Цитата: navrocky от Октябрь 15, 2010,  11:03
Тесты, работа с оборудованием, всякие специфические задачи, типа запустить программку подождать немного, обратиться...
Ну как бы подобные вещи принято делать в отдельных потоках и пусть они там себе ждут, если надо.
А вот для чего останавливать главный поток?
Записан
SASA
Гость
« Ответ #22 : Октябрь 15, 2010, 12:59 »
Цитата: navrocky от Октябрь 15, 2010,  11:03
Тесты, работа с оборудованием, всякие специфические задачи, типа запустить программку подождать немного, обратиться...
Тролтех подумал об этом void QTest::qSleep ( int ms ) Смеющийся
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #23 : Октябрь 15, 2010, 17:28 »
Цитата: BRE от Октябрь 15, 2010,  11:10
А вот для чего останавливать главный поток?
Да его только и делают что усыпляют  Улыбающийся Чем занимается главная нитка - ждет событий (на том же мутексе/семафоре), то же "усыпление".

Что касается sleep (в любой форме), то сколько раз я его ставил - столько же и убирал. Упирается в то что глупо ждать когда ответ уже есть. Так что sleep - для тестовых/отладочных целей, не более. Другое дело - напр ждать на семафоре заданное время, такая возможность есть.
Записан
Denjs
Гость
« Ответ #24 : Октябрь 15, 2010, 17:44 »
Цитата: Igors от Октябрь 15, 2010,  17:28
Что касается sleep (в любой форме), то сколько раз я его ставил - столько же и убирал. Упирается в то что глупо ждать когда ответ уже есть. Так что sleep - для тестовых/отладочных целей, не более. Другое дело - напр ждать на семафоре заданное время, такая возможность есть.
Sleep удобен когда работаешь с оборуоваием и реализуешь в одной процедуре некий протокол обмена данными.

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

Со слипом это прекрасно уложится в одну функцию. Короткую, простую, понятную.
Записан
navrocky
Гипер активный житель
*****
Offline Offline

Сообщений: 817


Погроммист


Просмотр профиля
« Ответ #25 : Октябрь 15, 2010, 18:09 »
Цитировать
Со слипом это прекрасно уложится в одну функцию. Короткую, простую, понятную.

Плюсую.
 
Что бы тут не говорили иногда sleep нужен, и тролли лучше бы сделали одну нормальную реализацию, чем плодили бы их в каждом модуле отдельно.. ну бог им судья. Я лично пользую sleep из буста...
Записан
Гугль в помощь
BRE
Гость
« Ответ #26 : Октябрь 15, 2010, 19:04 »
Цитата: Igors от Октябрь 15, 2010,  17:28
Да его только и делают что усыпляют  Улыбающийся Чем занимается главная нитка - ждет событий (на том же мутексе/семафоре), то же "усыпление".
Мы говорим конкретно про sleep в главном потоке, судя по следующему тексту ты это понял, для чего это "пояснение" про мютексы/семафоры? Или это не мне "пояснение" или ты думаешь я этого не знаю?

Цитата: Igors от Октябрь 15, 2010,  17:28
Упирается в то что глупо ждать когда ответ уже есть.
Золотые слова.
Записан
BRE
Гость
« Ответ #27 : Октябрь 15, 2010, 19:06 »
Цитата: Denjs от Октябрь 15, 2010,  17:44
Мол авторизация, 5 сек ждем ответа, команда, ждем ответа, выключиться, ждем статуса завершения.
Если описанное выше делать в асинхронной сигнал слотовой модели - мне нужно делать машину состояний с 4 состояниями, писать 3 процедуры и кучу проверок. И городить ещё и таймер , что бы отслеживать таймаут.
Для чего это делать в главном потоке? Запусти нитку и пусть она хоть по десять минут ждет ответа.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #28 : Октябрь 15, 2010, 19:18 »
Если не надо отслеживать cancel и перерисовывать окна (а за 5 сек это может понадобиться) - ну тогда конечно sleep всем хорош  Улыбающийся Ну да бог с ним, мы отвлеклись.

А вот как удалять созданный экземпляр t_returnSyncObject ? Я поприкидывал, но не вижу простого решения - сложновато получается. Какие есть мнения?
Записан
Denjs
Гость
« Ответ #29 : Октябрь 15, 2010, 19:54 »
Цитата: BRE от Октябрь 15, 2010,  19:06
Для чего это делать в главном потоке? Запусти нитку и пусть она хоть по десять минут ждет ответа.
А,... ну если так... )) но тут скорее вопрос не в главном потоке или нет, а в том, что как "заснуть" в методе класса?
т.е. у меня есть класс - я его засунул в параллельный поток. Потом срабатывает слот - и в этом слоте(слоту?)) мне надо сделать "описанный выше протокол". Я могу получить поток, в котором я сейчас нахожусь - но мне это ничего не даст. т.к. метод "поспать" у обычного QT-шного потока - частный. Приходится или извращаться, или делать кроссплатформенную обертку над ос-зависимыми функциями.

Вспомните - с чего данная нить разговора началась?)
Записан
Страниц: 1 [2] 3   Вверх
  Печать  
« предыдущая тема следующая тема »
 
Перейти в:  


Страница сгенерирована за 0.055 секунд. Запросов: 22.