Односторонняя передача информации между процессами?

Question

[Door]

Здравствуйте,

описываю ситуацию:

есть родительский процесс(WindowProc присутствует), который порождает новый, дочерний процесс. Дочернему процессу нужно как-то оповещать родительский процесс о прогрессе выполнения какой-то задачи — т.е., по сути, передавать числа от 0 до 100 (или от 0 до 1, не столь важно). Но нужно это делать без какой-либо задержки дочернего процесса (т.е. записать в memory map, отослать event и подождать другой event об успешности чтения нельзя; по той же причине, не получиться использовать pipe, поскольку нужно будет ждать «подключения» (ConnectNamedPipe)).


Есть какое-либо решение?

Comments

[kaladhara]

Процесс или поток?

[Door]

Процесс, ошибки нет.

[kaladhara]

Родительский процесс может дождаться пока дочерний с ним свяжется, или запустил и забыл?

[Door]

да, родительский процесс может ждать сколько угодно.

Answer 1

[kaladhara]

Сокеты подойдут?

Comments

[kaladhara]

(т.е. записать в memory map, отослать event и подождать другой event об успешности чтения нельзя)


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

[Door]

А как именно это всё нужно организовать, подскажите? а то я представление имею, но на практике не сталкивался с ними.

[kaladhara]

Родительский процесс создает глобальный event и [в одном из своих потоков] ожидает пока он засияет ярким пламенем.

Дочерний в ходе работы регулярно записывает чего куда, и делает setevent. Даже если родительский прочитает значение в момент записи дочерним — то и хрен с ним. Это если речь идет о прогрессбаре (хотя как решение попроще можно и просто postmessageм обойтись).

Если же нужно передавать более ценную информацию, тогда я бы сделал так чтобы только дочерний процесс владел безраздельно кое-чем, а уж родительский только пытался заполучить данные.

Хотя, честно говоря, я не понимаю как родительский может заставить ждать дочерний очень долго, ведь цена вопроса — залочить ресурс, считать несчастных 8 байт и вернуть ресурс обратно.

Распишите задачу более подробно — получите более конкретный ответ.

[Door]

гарантированная доставка — было бы не плохо, но я имел в виду, что синхронизировать всё это дело надо, так как если будет что-то такое(где pBuf — адресс mapped view):

for(int i = 0; i <= 100; ++i)
{
    CopyMemory(pBuf, &i, sizeof(i));
}

то читающий(родительский) процесс ведь ничего толкового не получит. Нужно сказать — «я закончил писать, ты можешь прочитать» — «а я закончил читать, ты можешь перезаписать».

P.S.: извините, под memory map я имел в виду file maping

[Door]

Хотя, честно говоря, я не понимаю как родительский может заставить ждать дочерний очень долго, ведь цена вопроса — залочить ресурс, считать несчастных 8 байт и вернуть ресурс обратно.

— родительский процесс может завершиться, событие никогда не перейдёт в сигнальное состояние, WaitForSingleObject с INFINITE (указывать максимальное время ожидания — не подходит) будет ждать вечно.

[kaladhara]

Если не подключать тяжелую артиллерию — PostMessage самое оно (только НЕ WM_USER+xxx, используйте RegisterWindowMessage).
Если же по какой-то причине этот вариант не подходит — повторюсь, опишите более детально задачу.

[kaladhara]

родительский процесс может завершиться, событие никогда не перейдёт в сигнальное состояние, WaitForSingleObject с INFINITE (указывать максимальное время ожидания — не подходит) будет ждать вечно

Почему это? Есть один объект, процессы пытаются завладеть им поочередно, если родитель завершится — ребенок просто регулярно будет овладевать этим объектом, и всё.

[Door]

Хорошо, если PostThreadMessage мне не подходит, то как для PostMessage передать HWND окна дочернему процессу? (FindWindow не подходит).

опишите более детально задачу

если можете и есть желание, спрашивайте в личку конкретные вопросы, а то я не знаю что ещё описать.
Спасибо.

[kaladhara]

Передать хендл проще всего в виде аргумента командной строки для процесса.

[Door]

Почему это? Есть один объект, процессы пытаются завладеть им поочередно, если родитель завершится — ребенок просто регулярно будет овладевать этим объектом, и всё.

немножко не понял, я представляю себе это так:

// родительский процесс

// открываем event, пытаемся открыть до тех пор, пока не получится
HANDLE hCanReadEvent = NULL;
do
{
	::Sleep(100);
	hCanReadEvent = ::OpenEvent(...);
}while(hCanReadEvent == NULL);

// ожидаем
::WaitForSingleObject(hCanReadEvent, INFINITE);
// допустим WaitForSingleObject успешно завершилась,
// имеем доступ к файлу, читаем его

// оповещать дочерний процесс о том, что мы прочитали и он может снова писать ?
// если да, то как ? - через event ? - если через event, то дочерний процесс
// должен ждать ? а если должен ждать, то может не дождаться, так как родительский
// процесс может завершиться, и event будет в несигнальном состоянии - дочерний процесс
// никогда не завершиться

[kaladhara]

// родитель

HANDLE m_file_owned=CreateMutex(0,FALSE,"я_владею_файлом");
HANDLE e_progress=CreateEvent(0,1,0,L"новые_данные");

...
запускаем детей
...
ждем от них вестей
switch (waitforsingeobject(e_progress,INFINITE))
{
case WAIT_OBJECT_0:
  пытаемся завладеть файлом
   switch(waitforsingleobject(m_file_owned,INFINITE))
   {
     case WAIT_OBJECT_0:
       читаем файл
       ResetEvent(e_progress); гасим событие
       ReleaseMutex(m_file_owned) отпускаем файл
   }
  break;
case WAIT_TIMEOUT:
...
}


// детский процесс

//НЕ делаем OpenEvent или OpenMutex!!!!
HANDLE m_file_owned=CreateMutex(0,FALSE,"я_владею_файлом");
HANDLE e_progress=CreateEvent(0,1,0,L"новые_данные");

...
for (...;...;...)
{
...
switch (waitforsingleobject(m_file_owned,0)) // НЕ ЖДЕМ ДО БЕСКОНЕЧНОСТИ!!!
{
  case WAIT_OBJECT_0:
    пишем в файл
    ReleaseMutex(m_file_owned); отпускаем файл
   SetEvent(e_progress); оповещаем об новых данных
}

всё.
Хотя можно обойтись одним Eventом.

[mayorovp]

У мьютексов есть защита — если поток, владеющий мьютексом, завершится — мьютекс будет автоматически освобожден.

Answer 2

[vScherba]

Можно использовать оконные сообщения WM_USER через PostMessage. У Вас передаются целые числа, которые влезают в lParam, wParam, так что даже не придется перекачивать данные через общую память, пайпы и сокеты.
Даже не обязательно создавать для этого окно, можно использовать PostThreadMessage.
В родительском процессе читать уведомление в цикле выработки сообщений. Если такового нет, то создать в новом потоке.

Comments

[Door]

PostThreadMessage:

Messages sent by PostThreadMessage are not associated with a window. As a general rule, messages that are not associated with a window cannot be dispatched by the DispatchMessage function. Therefore, if the recipient thread is in a modal loop (as used by MessageBox or DialogBox), the messages will be lost. To intercept thread messages while in a modal loop, use a thread-specific hook.
The system only does marshalling for system messages (those in the range 0 to (WM_USER-1)). To send other messages (those >= WM_USER) to another process, you must do custom marshalling.

у меня и DialogBox и messages >= WM_USER

[vScherba]

В таком случае, создайте скрытое окно и в его процедуре обрабатывайте прогресс, а сообщение из другого процесса шлите ему стандартным PostMessage(hwnd_скрытого_окна, WM_USER, N1, N2). Маршалинг Вам не нужен при передаче long значения в lParam или wParam.

Answer 3

[mayorovp]

Мои варианты:

1. Самый простой — stdout, он же стандартный вывод. Если перенаправить его в анонимный канал, то родительский процесс сможет читать, что туда пишет дочерний. Если родительский процесс завершится, дочерний будет получать ошибку при записи в канал. Зависание дочернего процесса возможно только в одном случае — если он запишет в канал более 4КБ текста, а родитель не будет этого читать.

2. Аналогичный первому — создать пару TCP-сокетов, соединенных друг с другом. Достоинство — дочерний процесс теперь может использовать неблокирующий режим, что предотвратит его блокировку (ценой потери части данных в том случае, когда родитель их не читает).

3. Просто использовать циклический буфер в разделяемой памяти, с односторонней установкой некоторого события. Можно даже использовать буфер размера 1 — то есть всегда записывать в одно и то же место. Данные могут теряться, но для уведомления о прогрессе это несущественно.

4. Использовать общий семафор — дочерний процесс делает Release, родитель — Wait. Недостаток — невозможно асинхронное ожидание, нет передачи, собственно, сообщений — только подсчет.

Answer 4

[Razario777]

Если по каким-то причинам нельзя перенаправить вывод, то я бы выбрал UDP.