Как "усыпить" текущий поток?

[ритт]

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

[Winstrol]

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

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

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

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

[spectre71]

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

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

[ритт]

что-т я последний мессаг не понял - из-за чего будет подвисание? если сохраняешь копию, то вообще всё замечательно - повесил часики, снял снапшот(ы) в гуёвом потоке, убрал часики и в новом потоке сохраняешь снап...интерфейс вообще можно блокировать только на время копирования объектов в памяти...

[ритт]

кстати, вот - http://doc.trolltech.com/qq/qq27-responsive-guis.html

[spectre71]

что-т я последний мессаг не понял - из-за чего будет подвисание? если сохраняешь копию, то вообще всё замечательно - повесил часики, снял снапшот(ы) в гуёвом потоке, убрал часики и в новом потоке сохраняешь снап...интерфейс вообще можно блокировать только на время копирования объектов в памяти...

Собственно я имел ввиду под подвисанием "часики", если проект большой, то это могут быть секунды, а если очень очень, то и десятки секунд, что неприятно для пользователя.

[spectre71]

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

[Winstrol]

Кстати, натолкнулся на ситуацию когда точно нужен "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]

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

Чем плох политкорректый код из ссылки Константина?
...
...

А тем, что не имеет к этому отношения.

[spectre71]

Если интересно, вот как выглядит сохранение сейчас.
Только у "gif" цвета срезаются.

[BRE]

Как предложение. IMHO, лучше пусть в сплэше быстро мелькают имена проектов, и сохранение происходит быстрее. А для информирования пользователя завести журнал действий (log), в котором и выводить подробную информацию:
Сохраняется проект "ААА" - Ок
Сохраняется проект "БББ" - Ок
....
В него можно записывать и другие действия с подробными комментариями. Разместить его в закладке после Debug, например.

[Winstrol]

Как предложение. IMHO, лучше пусть в сплэше быстро мелькают имена проектов, и сохранение происходит быстрее.

ИМХО обращения к GUI потоку из вычислительных потоков должны быть ассинхронными. А GUI пусть сам разбирается с помощью таймеров и событий, сколько что показывать. Но автор предпочитает идти своим путем и блокировать вычислительный поток.
Кстати, фиктивный QWaitCondition никто не отменял.

[BRE]

ИМХО обращения к GUI потоку из вычислительных потоков должны быть ассинхронными. А GUI пусть сам разбирается с помощью таймеров и событий, сколько что показывать. Но автор предпочитает идти своим путем и блокировать вычислительный поток.
Кстати, фиктивный QWaitCondition никто не отменял.

Мое мнение, не надо вообще ничего замедлять! Я об это уже несколько раз писал.
А где автор будет делать сохранение (в основном потоке или в специальном), это его дело.
Не нужно дополнительно тормозить работу пользователя, ради вывода каких-то незначительных и не нужных ему сообщений.

[Winstrol]

Мое мнение, не надо вообще ничего замедлять! Я об это уже несколько раз писал.
А где автор будет делать сохранение (в основном потоке или в специальном), это его дело.
Не нужно дополнительно тормозить работу пользователя, ради вывода каких-то незначительных и не нужных ему сообщений.

ИМХО это вопрос вкуса, как обрабатывать сигнал сохраняющего потока. Либо показать окно, либо записать сообщение в лог. В обоих случаях потоку, реализующему сохранение, ничего не нужно знать о конкретной выбранной стратегии взаимодействия с пользователем. Его забота сохранять и сигналы кидать о текущем прогрессе.

[BRE]

ИМХО это вопрос вкуса, как обрабатывать сигнал сохраняющего потока. Либо показать окно, либо записать сообщение в лог. В обоих случаях потоку, реализующему сохранение, ничего не нужно знать о конкретной выбранной стратегии взаимодействия с пользователем. Его забота сохранять и сигналы кидать о текущем прогрессе.

Какие потоки сохранения? 
Разговор завязался о целесообразности усыпления программы, для того чтобы пользователь успел прочитать сообщение. Я пишу только о этом.