технология работы с QSharedMemory

[ilyagoo]

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

спасибо.

[lex_newton]

Сложно сказать, что выгоднее. Не до конца ясна задача и частота обращения read\write. Возможно, вам подойдет как signal\slot так и другие механизмы. нужно подробно смотреть.

[ilyagoo]

Возможно, вам подойдет как signal\slot

нет, разные процессы.

задача - увести большой объем информации из некоего подобия драйвера для ее обработки.
запись в данный момент ориентировочно 60 раз в секунду по 131027 байта. в недалеком будущем трафик может быть равен 120 Мб/с пачками побольше.
пишуший процесс нежелательно блокировать чтением в другом процессе.

[lex_newton]

Хм.. значит, у нас есть один процесс который производит чтение данных в очередь(условно назовем так структуру данных).

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

[ilyagoo]

для простоты картины назовем эту очередь циклическим буфером))
есть два варианта работы:
1) процесс-обработчик (ПО) попросил некоторые данные и дал команду процессу-драйверу (ПД) их класть в буфер. ПО знает необходимое ему количество и может остановить драйвер когда его (кол-во) получит. тут возможны варианты управления:
    - ПО может сказать ПД это количестно и ПД остановится сам
    - ПО может проверять кол-во данных в буфере и дать команду остановки ПД
после обработки данные становятся ненужными.

2) ПО просит ПД начать трансляцию данных потоком, при этом ПО волен выбрать некоторый кусок потока и обработать его. в произвольный момент времени ПО может остановить ПД.

[lex_newton]

Ага. теперь стало намного понятней
На самом деле - я не совсем понимаю зачем QSharedMemory. Возможно, есть смысл передавать данные сразу через что-нибудь вроде pipe. Тогда можно будет избежать необходимости синхронизации(в связи с которой будет остановка потока производящего запись в буфер) и избежать затирания данных в кольцевом буфере, в случае переполнения.
Насчет управления этим процессом - можно воспользоваться такой штукой: QRemoveSignal ( http://qt-apps.org/content/show.php/QRemoteSignal?content=112061 ). или же через каналы(самый простой и понятный вариант)
Если все же shared memory небходимо, то без блокировки на время чтения\записи - никуда не деться. или шаманить алгоритм препятствующий возникновению коллизий

[ilyagoo]

был вариант обмена через сокеты, но то ли я что-то сделал не лучшим образом, то ли у них есть некий предел, но мне удалось прокачать чуть больше 60 Мб/с на локальной машине. есть ли предел скорости и размера буфера у канала? у сокета? имеется в виду pipe винды?

[lex_newton]

Если честно - на таких скоростях я не тестировал... даж не знаю какую технологию предложить

[Igors]

Я делал такое на shared memory + семафоры между процессами (тоже нужна была скорость). ничего страшного нет

[ilyagoo]

я и не боюсь))
вопрос в том, как этим управлять.
и еще вдруг кто-нибудь оценивал производительность сокетов и пайпов...

[Igors]

я и не боюсь))
вопрос в том, как этим управлять.
и еще вдруг кто-нибудь оценивал производительность сокетов и пайпов...

Ну быстрее чем через shared memory - точно не будет 
Управлять просто: 2 семафора, сигналите по одному и ждете на другом. Для др. процесса аналогично - просто семафоры меняются местами. Это максимально упрощенно/примитивно, но часто больше и не требуется