Russian Qt Forum

Эффективные с точки зрения пропускной способности и нагрузки на основной поток.
Задача: надо из одного (не GUI) потока, передать в другой поток блоками здоровенный файл. Банальная попытка сделать это через SIGNAL/SLOT провалилась, т.к. передача всего этого шла через основной поток (т.к. SIGNAL при испускании лезет именно в основную очередь).
Так же очень неудобно вызывать в потоке exec для приема сигналов, т.к. требуется выполнять и другую фоновую работу, а делать это по таймерам - бред. Это всё загружает очередь основного потока и увеличивает время отклика приложения, что не желательно.
В Windows были замечательные объекты Event (которые можно было ставить в одном потоке, проверять состояние в другом, и ждать пока другой поток его поставит).
Кто что подскажет для реализации сего в Qt?
P.S. Передача проводилась кусками QByteArray (что должно быть эффективно с точки зрения экономии памяти).

Вопросик: А поток-приёмник не может читать сам файл? Допустим из потока-источника передаеться смещение и размер блока в файле, а поток-приёмник сам читает этот блок из файла.

в Qt тоже есть QEvent, должно помочь...

Можно также производить обмен через выделенную область памяти. Писать в неё данные и испускать сигнал на чтение данных. Только нужно не забывать об объектах синхронизации

QEvent совсем не то. Я о том, что очередь главного потока очень легко засоряется, если постоянно вызывать сигналы/слоты. Большой файл я привел как пример быстрого потока данных. Кому не нравится файл, представьте себе сокет.

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

обрисуй задачу более конкретно, чтобы не экстрасенсировать тут...

Собственно говоря прозвучало уже несколько предложений. Реальзация и все предложения зависят от источника данных. Опишите что имено вам нужно: что и куда будет передаваться.

Пускай это будет генератор случайных чисел создающий 10-20Мб в секунду в одном потоке, сохранение этого мусора в другом.
Дописал: программа откликается, но совсем не так быстро, как могла бы. Проц. двуядерный, основной поток работает на первом ядре, всё остальное на другом.

Вроде как "передавать блоки" нет нужды, т.к. потоки в одном приложении и память общая.
Если задача стоит так: есть поток генератьр и поток(и) получатель(и).
Тогда можно организовать очередь из блоков, доступ к которой контролируется QMutex-ом.
Если что-то сложнее - есть ещё например QReadWriteLock...

Если дело протекает на одной машине то кури:
http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=mmap&category=2
там все и синхронизация и етц..., это уж точно эффективнее с точки зрения всего, так как за все отвечает ОС а в кутэ есть класс пользующий их QSharedMemory называется начиная с 4.4 :)

ГЫ ;) Плохо представил - тут вчера как раз одному товарисчу читал нотацию на эту тему - У нас на одной из железок на сокете висит хароооошая АЦП и при отлпдке используеться поток в районе 6 Гигабит .... Решение в лоб было - в потоке   читаем блок   , пихаем в другой сокет ( на вход ДСП) и читаем (в другом потоке) со входа ДСП данные ,которые Eventom перекидывались на график ...... В общем АМД с 2 гигами памяти сдох сразу ( слайд шоу) ,Intel работал нормально (почти) но все-равно весело ;) Сокеты рааазные бывают ;)

Плохо у мя с русским. Вопрос не в том, как передать данные ) QMutex'ом QList<QByteArray> защитить не проблема. Проблема в передаче во второй поток сообщения о том, что к нему в список уже пришло List::size() буферов и пора бы уже всё обработать )) А, размер буфера у мя 20кБ (ну чтобы буферов мнооого было)

Можно вообще без сообщений: кури QWaitCondition.

Кажется, что это классическая задача http://www.crossplatform.ru/?q=node/313 смотреть Example: Bounded Buffers