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

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

Страниц: 1 2 3 [4] 5   Вниз
  Печать  
Автор Тема: Как "усыпить" текущий поток?  (Прочитано 36340 раз)
ритт
Гость
« Ответ #45 : Июль 09, 2009, 08:26 »

я бы советовал взять за пример сохранение в кореле - там объекты могут исчисляться далеко не десятками тысяч - вот тогда-то и начинаются настоящие тормоза при открытии/сохранении...так они просто блокируют текущий документ на редактирование, а в статусбаре (если не вру) появляется прогрессбар с именем файла а-ля "файл_такой-то.цдр 50%"
хоть камень и загружен в это время на 99%, всё-равно можно в это время что-то делать. а на многоядерных железках вообще никаких неудобств
Записан
Winstrol
Гость
« Ответ #46 : Июль 09, 2009, 08:40 »

А в чем проблема сделать отдельный поток? Одна строка

futureWatcher.setFuture(QtConcurrent::run(&serializer,&Serializer::start));

Плюс сигналы finished() подключить и сигналы сообщающие о прогрессе внутри процедуры сериализации.

А вот менять данные в одном потоке, а в другом сохранять плохо. Изменения могут проходить неатомарно и изменения могут быть считаны в промежуточном состоянии.
« Последнее редактирование: Июль 09, 2009, 08:57 от Winstrol » Записан
spectre71
Гость
« Ответ #47 : Июль 09, 2009, 09:46 »

я бы советовал взять за пример сохранение в кореле - там объекты могут исчисляться далеко не десятками тысяч - вот тогда-то и начинаются настоящие тормоза при открытии/сохранении...так они просто блокируют текущий документ на редактирование, а в статусбаре (если не вру) появляется прогрессбар с именем файла а-ля "файл_такой-то.цдр 50%"
хоть камень и загружен в это время на 99%, всё-равно можно в это время что-то делать. а на многоядерных железках вообще никаких неудобств

Ну, у меня сейчас для тестирования открыто 28 проектов и 425791 объектов которые сериализуются и сохраняются(~50% объектов ), специально в дибаг версии вывожу кол-во объектов(наследуемых от моего сериализуемого класса RW) в статус баре. Так вот, сохранение всех проектов(~200000  объектов, 28 файлов)  занимает 3-4 сек, а поднятие 5-6 сек.
Задача сводить к созданию копии проекта(в памяти) и сохранении уже копии. Поскольку некоторые проекты могут быть большими, то в общем случае операция может быть длительной и подвесит пользотельский интерфейс. Для копирования в другом потоке необходимо будет вставить в массу мест критическую секцию(на момент копирования), да еще и так чтобы блокировать только необходимые операции, иначе получиться все тоже подвисание интерфейса. Короче без хорошего рефакторинга не обойтись.
Записан
ритт
Гость
« Ответ #48 : Июль 09, 2009, 10:05 »

что-т я последний мессаг не понял - из-за чего будет подвисание? если сохраняешь копию, то вообще всё замечательно - повесил часики, снял снапшот(ы) в гуёвом потоке, убрал часики и в новом потоке сохраняешь снап...интерфейс вообще можно блокировать только на время копирования объектов в памяти...
Записан
ритт
Гость
« Ответ #49 : Июль 09, 2009, 10:20 »

кстати, вот - http://doc.trolltech.com/qq/qq27-responsive-guis.html
Записан
spectre71
Гость
« Ответ #50 : Июль 09, 2009, 11:56 »

что-т я последний мессаг не понял - из-за чего будет подвисание? если сохраняешь копию, то вообще всё замечательно - повесил часики, снял снапшот(ы) в гуёвом потоке, убрал часики и в новом потоке сохраняешь снап...интерфейс вообще можно блокировать только на время копирования объектов в памяти...
Собственно я имел ввиду под подвисанием "часики", если проект большой, то это могут быть секунды, а если очень очень, то и десятки секунд, что неприятно для пользователя.
Записан
spectre71
Гость
« Ответ #51 : Июль 09, 2009, 12:02 »

Кстати, натолкнулся на ситуацию когда точно нужен "public : sleep"!
Создаю QThread, в run вызываю метод некоторого объекта, а в методе объекта требуется sleep!
Записан
Winstrol
Гость
« Ответ #52 : Июль 09, 2009, 12:32 »

Кстати, натолкнулся на ситуацию когда точно нужен "public : sleep"!
Создаю QThread, в run вызываю метод некоторого объекта, а в методе объекта требуется sleep!
Чем плох политкорректый код из ссылки Константина?


Код
C++ (Qt)
QEventLoop q;
QTimer tT;
 
tT.setSingleShot(true);
connect(&tT, SIGNAL(timeout()), &q, SLOT(quit()));
tT.start(5000); // 5s timeout
q.exec();
 
Записан
spectre71
Гость
« Ответ #53 : Июль 09, 2009, 12:51 »

Кстати, натолкнулся на ситуацию когда точно нужен "public : sleep"!
Создаю QThread, в run вызываю метод некоторого объекта, а в методе объекта требуется sleep!
Чем плох политкорректый код из ссылки Константина?
...
...

А тем, что не имеет к этому отношения.
Записан
spectre71
Гость
« Ответ #54 : Июль 09, 2009, 13:02 »

Если интересно, вот как выглядит сохранение сейчас.
Только у "gif" цвета срезаются.
Записан
BRE
Гость
« Ответ #55 : Июль 09, 2009, 13:56 »

Как предложение. IMHO, лучше пусть в сплэше быстро мелькают имена проектов, и сохранение происходит быстрее. А для информирования пользователя завести журнал действий (log), в котором и выводить подробную информацию:
Сохраняется проект "ААА" - Ок
Сохраняется проект "БББ" - Ок
....
В него можно записывать и другие действия с подробными комментариями. Разместить его в закладке после Debug, например.
Записан
Winstrol
Гость
« Ответ #56 : Июль 09, 2009, 14:12 »

Как предложение. IMHO, лучше пусть в сплэше быстро мелькают имена проектов, и сохранение происходит быстрее.
ИМХО обращения к GUI потоку из вычислительных потоков должны быть ассинхронными. А GUI пусть сам разбирается с помощью таймеров и событий, сколько что показывать. Но автор предпочитает идти своим путем и блокировать вычислительный поток.
Кстати, фиктивный QWaitCondition никто не отменял.
Записан
BRE
Гость
« Ответ #57 : Июль 09, 2009, 14:22 »

ИМХО обращения к GUI потоку из вычислительных потоков должны быть ассинхронными. А GUI пусть сам разбирается с помощью таймеров и событий, сколько что показывать. Но автор предпочитает идти своим путем и блокировать вычислительный поток.
Кстати, фиктивный QWaitCondition никто не отменял.
Мое мнение, не надо вообще ничего замедлять! Я об это уже несколько раз писал.
А где автор будет делать сохранение (в основном потоке или в специальном), это его дело.
Не нужно дополнительно тормозить работу пользователя, ради вывода каких-то незначительных и не нужных ему сообщений.
Записан
Winstrol
Гость
« Ответ #58 : Июль 09, 2009, 14:41 »

Мое мнение, не надо вообще ничего замедлять! Я об это уже несколько раз писал.
А где автор будет делать сохранение (в основном потоке или в специальном), это его дело.
Не нужно дополнительно тормозить работу пользователя, ради вывода каких-то незначительных и не нужных ему сообщений.
ИМХО это вопрос вкуса, как обрабатывать сигнал сохраняющего потока. Либо показать окно, либо записать сообщение в лог. В обоих случаях потоку, реализующему сохранение, ничего не нужно знать о конкретной выбранной стратегии взаимодействия с пользователем. Его забота сохранять и сигналы кидать о текущем прогрессе.
Записан
BRE
Гость
« Ответ #59 : Июль 09, 2009, 16:15 »

ИМХО это вопрос вкуса, как обрабатывать сигнал сохраняющего потока. Либо показать окно, либо записать сообщение в лог. В обоих случаях потоку, реализующему сохранение, ничего не нужно знать о конкретной выбранной стратегии взаимодействия с пользователем. Его забота сохранять и сигналы кидать о текущем прогрессе.
Какие потоки сохранения?  Подмигивающий
Разговор завязался о целесообразности усыпления программы, для того чтобы пользователь успел прочитать сообщение. Я пишу только о этом.  Улыбающийся
Записан
Страниц: 1 2 3 [4] 5   Вверх
  Печать  
 
Перейти в:  


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