Как передать команду (число) в другой процесс?

[jur]

Привет!

Возникла примитивная задача, про которую я сначала подумал, что щелкать семечки по-сравнению с ней - тяжелый труд :-) Мне нужно просто-напросто передать команду (число типа int) в другой процесс. Какие проблемы? PostMessage и все дела! Благо HWND его (в смысле, другого процесса) окна я знаю. Команда, конечно, собственная, из диапазона > WM_USER. Оказывается не все так просто! (Ёлки! Думается, что в Микрософте рулят сплошь бывшие советские комсомольцы: им, видите ли, не интересно, если не в гамаке на лыжах и с аквалангом...)

Ладно, начал углубляться в этот вопрос. Много чего просмотрел, с интересом прочитал топик Взаимодействие процессов - яснее не стало. Не, я понимаю, что через какой-нить Memory mapped file это сделать можно. Но хотелось бы попроще...

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

Дело осложняется тем, что того, другого процесса может не быть. Никакой очереди мне не нужно, посланная команда должна замещаться новой, если другой процесс не прочитал предыдущую (это когда другой процесс вообще не запущен). Никакие таймауты не допустимы: не прочитал другой процесс команду пока пришла следующая - ну и черт с ней, со старой командой. Т.е. этот канал передачи чисел должен работать в точности, как простой RS-232 без хэндшейка: посылает числа хоть другому процессу, хоть на деревню дедушке... :-)

Как решить такую задачу максимально просто, несколькими строками текста программы (ну ладно, пол-странички)?

Спасибо!

P.S. Система Win XP, самое обычное PC-совместимое железо. 2008-я Студия, C/C++.

[zubr]

1. FindWindowEx - находим все окна определенного класса, желательно с уникальным именем, соответствующие процессам, в которые надо передавать сообщения.
2. SendMessage в найденные окна.

[jur]

1. FindWindowEx - находим все окна определенного класса, желательно с уникальным именем, соответствующие процессам, в которые надо передавать сообщения.

Этого не нужно. Я же написал: HWND окна другого процесса я знаю.

2. SendMessage в найденные окна.

Не годится. SendMessage ждет получения сообщения другим окном. А я писал, что ждать нельзя: "Никакие таймауты не допустимы: не прочитал другой процесс команду пока пришла следующая - ну и черт с ней, со старой командой." Т.е. полностью устраивает команда PostMessage, но она не работает с сообщениями > WM_USER.

P.S. Точнее, работает, но "... в гамаке и с аквалангом..." :-)

[Вад]

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

Может, каналы и использовать тогда: сокеты или пайпы попробовать?

[zubr]

Не годится. SendMessage ждет получения сообщения другим окном. А я писал, что ждать нельзя: "Никакие таймауты не допустимы: не прочитал другой процесс команду пока пришла следующая - ну и черт с ней, со старой командой." Т.е. полностью устраивает команда PostMessage, но она не работает с сообщениями > WM_USER.

Ну CreateThread еще никто не отменял.

[Dimka]

Вад, в pipe'ах он не перезапишет ранее ушедшее. А при отсутствии подключения с той стороны буфер переполнится, и всё упадёт.

Либо в отдельном потоке крутить цикл опроса глобальной (межпоточной volatile переменной) и делать sendmessage. Либо сделать MemoryMappedFile - по сути глобальную межпроцессную область памяти тоже с volatile переменной.

Второй вариант с (MemoryMappedFile) предпочтительнее как с точки зрения быстродействия, так и с точки зрения простоты подключения клиентов-читателей, каковых может быть много. Но у него есть проблема с уведомлением клиентов об изменении данных. UNIX-сигналы в Windows работают скверно - по сути запускаются отдельные потоки внутри процесса для обработки сигнала, т.е. это не прерывание процесса, и возникает проблема синхронизации. SendMessage в этом плане ведёт себя хорошо, но у клиента нет возможности узнать, какие из сообщений пропускать. Кроме того, не вполне понятно, что будет при попытке сервера оборвать текущий SendMessage, когда на клиенте он стоит в очереди сообщений.

[jur]

Интересная задача получилась! :-) В общем, склоняюсь к такому решению (согласен с уважаемым коллегой Dimka).

1. Данные будут помещаться в память, что позволит в будущем расширить размер передаваемой информации сверх простого числа. Иными словами Memory mapped file. Это позволит перезаписывать отправляемые данные, не заботясь о их получении другим процессом.

2. Для оповещения всех желающих о поступлении новых данных используется именованный ивент. Ожидает его кто-нибудь, или нет - до лампочки. "Мое дело сказать - я сказал. А вы сидите на мели, не сидите на мели - у нас в машине куча дел и без вас!" (С) :-)

3. Для возможности получения исключительного доступа к данным используется именованный мьютекс (без хозяина, конечно). Захватил - записал/прочитал - освободил.

Вот как-то так. Завтра попробую и отпишусь о результатах. Прельщает в таком решении то, что оно один-в-один похоже на простой RS-232 без хэндшейка :-)

SendMessage ждет получения сообщения другим окном.

Ну CreateThread еще никто не отменял.

Увы, все равно не пройдет. Потому, что SendMessage в своем триде повиснет на передаче числа (если другого процесса нема) и не будет больше ни на что реагировать. Это не фатально, конечно, но как-то не очень... Не люблю, когда код на чем-то повисает, неприятно...

[zubr]

Увы, все равно не пройдет. Потому, что SendMessage в своем триде повиснет на передаче числа (если другого процесса нема) и не будет больше ни на что реагировать. Это не фатально, конечно, но как-то не очень... Не люблю, когда код на чем-то повисает, неприятно...

Глупости. Если нет процесса, нет окна, соответственно хендл неликвидный, SendMessage просто вернет ошибку. Да и проверять можно перед вызовом наличие окна.

[Dimka]

Для оповещения всех желающих о поступлении новых данных используется именованный ивент. Ожидает его кто-нибудь, или нет - до лампочки. "Мое дело сказать - я сказал. А вы сидите на мели, не сидите на мели - у нас в машине куча дел и без вас!"

Это подходит только для одиночного клиента. Причём нужен AutoEvent, иначе будет риск пропуска сообщения.

Для возможности получения исключительного доступа к данным используется именованный мьютекс (без хозяина, конечно). Захватил - записал/прочитал - освободил.

Это противоречит задаче "не тормозить" пишущий процесс. Тогда нужно ожидание с таймаутом.

[jur]

Если нет процесса, нет окна, соответственно хендл неликвидный, SendMessage просто вернет ошибку. Да и проверять можно перед вызовом наличие окна.

С одной стороны - да, можно. Но с другой стороны, неизвестно, сколько ждать, если то, другое окно есть. Оно может далеко не сразу получить это сообщение. Прямой вызов SendMessage в этом случае неприемлем из-за возможных задержек. Если же всю эту бодягу помещать в отдельный трид, со всеми необходимыми средствами синхронизации, то получится еще сложнее, чем с Memory mapped file.

Это подходит только для одиночного клиента. Причём нужен AutoEvent, иначе будет риск пропуска сообщения.

Да, клиент один. С этим вопросом проблем нет.

Для возможности получения исключительного доступа к данным используется именованный мьютекс (без хозяина, конечно). Захватил - записал/прочитал - освободил.

Это противоречит задаче "не тормозить" пишущий процесс. Тогда нужно ожидание с таймаутом.

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

[zubr]

Если же всю эту бодягу помещать в отдельный трид, со всеми необходимыми средствами синхронизации, то получится еще сложнее, чем с Memory mapped file.

В том то и фишка, что с SendMessage никакой синхронизации не надо, в отличие от файлмаппинга. Как только надо послать сообщение создаешь новый поток с единственной командой SendMessage, хендл потока сразу закрываешь. Ну для очистки совести, на случай если процесс принимающий сообщения вдруг завис, можно прикрутить чистилку потоков, которая будет через определенный интервал проверять состояние потоков и тем которые висят больше допустимого времени делать терминайт.

[jur]

В том то и фишка, что с SendMessage никакой синхронизации не надо, в отличие от файлмаппинга. Как только надо послать сообщение создаешь новый поток с единственной командой SendMessage, хендл потока сразу закрываешь. Ну для очистки совести, на случай если процесс принимающий сообщения вдруг завис, можно прикрутить чистилку потоков, которая будет через определенный интервал проверять состояние потоков и тем которые висят больше допустимого времени делать терминайт.

Недопонял... Сложно как-то...

Расскажу, что у меня в мозгу сложилось с помощью уважаемого коллеги Dimka. Я применяю ивент, мьютекс и файлмаппинг для организации передающего канала (а-ля простейший RS-232), который ничуть не влияет на работу основной программы, нисколько ее не тормозит и просто посылает данные тем, кто готов их получить. Никто не захочет - и прекрасно, программа работает без проблем. Плюс тот, что в главной программе я вставлю единственную строку текста, что-то вроде SendData(command, my_data, my_data_size);

В случае же SendMessage мне все равно придется городить трид, а кроме того в головной программе делать "чистилку потоков".

Сравниваю плюсы и минусы. Получается: ивент с мьютексом и файлом - против трида с чистильщиком и SendMessage. Первый вариант, IMHO, проще :-) Кроме того, он сулит возможность в будущем передавать еще и блок данных, а не просто число. Это - хорошо. (Типа, команда "юзер подвинул ползунок N 3" и тут же массив из 8 байт с новыми значениями положений всех ползунков. Пока не нужно, но удобно, если понадобится. Так сказать, задел на будущее.)

P.S. Сейчас мне даже мьютекса не нужно, т.к. передается просто число. Мьютекс - это на будущее, чтобы передавать небольшие блоки данных.

[zubr]

На самом деле с SendMessage все просто, тут и пол-страницы кода не нужно:

Код:

typedef struct Thread_Data
{
	HWND hwnd;
        DWORD number;
}THREAD_DATA, *PTHREAD_DATA;

DWORD WINAPI SendThreadProc(LPVOID lpParameter)
{
       PTHREAD_DATA phtd = (PTHREAD_DATA)lpParameter;
       if(!IsWindow(phtd->hwnd))
       {
              VirtualFree(phtd, 0, MEM_RELEASE);
             return 0;
       }
       SendMessage(phtd->hwnd, WM_USER + 1, phtd->number, 0);
       VirtualFree(phtd, 0, MEM_RELEASE);
       return 1;
}

DWORD WINAPI DispathThreadProc(LPVOID lpParameter)
{
        if(!lpParameter)
        return 0;
        HANDLE hThread = CreateThread(NULL, 0, SendThreadProc, lpParameter, 0, NULL);
        if(!hThread)
        return 0;
        if(WaitForSingleObect(hThread, 1000/*ждем секунду*/) != WAIT_OBJECT_0)
        TerminateThread(hThread, 0);
        CloseHandle(hThread);
        return 1;
}

int main()
{
      //отправка сообщения
      PTHREAD_DATA pthrd = (PTHREAD_DATA)VirtualAlloc(NULL, sizeof(THREAD_DATA), MEM_COMMIT, PAGE_READWRITE);      
      pthrd->hwnd = 123;
      pthrd->number = 123;
      HANDLE hThread = CreateThread(NULL, 0, DispathThreadProc, pthrd, 0, NULL);
      CloseHandle(hThread);
}

Что касается передачи блока данных, то тогда, имхо проще вообще через файл все решить. На стороне сервера запись данных в определенный файл, на стороне клиента ставим нотификатор на этот файл и по WaitForSingleObject читаем файл. Тогда не надо двусторонней синхронизации и сопутствующим заморочкам с правами пользователя. Конечно, если скорость обмена данными не критична.

[Dimka]

zubr, лишние потоки лучше, конечно, не создавать - использовать пул. Однако там, где надо обрывать зависшие потоки, пул не подходит.

Код: (C++)

#include <Windows.h>

class Post
{

private:

        struct Parameter
        {
                Post *Instance;
                int Value;

                Parameter(Post *instance, int value) :
                        Instance(instance),
                        Value(value)
                {}
        };

        static const int Timeout = 1000;

        const HWND targetWindowHandle;
        const UINT message;

        static DWORD WINAPI post(LPVOID parameter)
        {
                Parameter *argument = static_cast<Parameter *>(parameter);
                Post *instance = argument->Instance;
                int value = argument->Value;
                delete argument;
                instance->Send(value);
                return 0;
        }

        static DWORD WINAPI work(LPVOID parameter)
        {
                HANDLE thread = CreateThread(NULL, 0, Post::post, parameter, 0, NULL);
                DWORD wait = WaitForSingleObject(thread, Post::Timeout);
                if(wait != WAIT_OBJECT_0)
                {
                        TerminateThread(thread, 1);
                }
                CloseHandle(thread);
                return 0;
        }

public:

        Post(const HWND targetWinowHandle, const UINT message) :
                targetWindowHandle(targetWindowHandle),
                message(message)
        {}

        void Send(int value)
        {
                SendMessage(this->targetWindowHandle, WM_USER + this->message, value, NULL);
        }

        void AsyncSend(int value)
        {
                QueueUserWorkItem(Post::work, new Parameter(this, value), WT_EXECUTEDEFAULT);
        }

};

// ...

Post post(FindWindow(NULL, "Диспетчер задач Windows"), 1);
post.AsyncSend(3);

Но и у тебя и тут нет сброса предыдущего значения, если новое пришло до того, как предыдущее было обработано.

[jur]

Дааа... Разных вариантов немало. Придется еще более тщательно все обдумать и провести эксперименты. Тут деньком/другим не обойдешься. Вот прямо завтра и начну. Хотя понедельник и "день тяжелый"... :-)

P.S. О результатах отпишусь, как и обещал. Может кому-нибудь они окажутся полезными.

[Вад]

Вад, в pipe'ах он не перезапишет ранее ушедшее. А при отсутствии подключения с той стороны буфер переполнится, и всё упадёт.

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

[Dimka]

Пишущий ведь может вытирать историю?

Каким образом? Pipe - это ж поток (побайтовый или поблоковый). Если из процесса ушло в буфер ядра ОС, так ушло - с концами. Работа как с последовательным файлом: CreateNamedPipe, CreateFile, ReadFile, WriteFile, FlushFileBuffers. Дополнительно: ConnectNamedPipe - узнать о подключении клиента, DisconnectNamedPipe - принудительно отключить клиента, WaitNamedPipe - ждать прихода данных без чтения, PeekNamedPipe - читать без выталкивания. А вот писать без вталкивания - нет такого.

[zubr]

Но и у тебя и тут нет сброса предыдущего значения, если новое пришло до того, как предыдущее было обработано.

Dimka, так вроде по условию это не требуется.

[Dimka]

Dimka, так вроде по условию это не требуется.

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

[zubr]

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

[Dimka]

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

Но это всё "академические упражнения", поскольку способ не расширяется на произвольную структуру - WM_USER-сообщения не сериализуются автоматически, и надо ещё marshalling городить. Продолжаю считать MemoryMappedFile более предпочтительным вариантом - с именованным мьютексом для синхронизации доступа. А вот именованный autoevent не расширяется на много клиентов - увы. Выдача каждому клиенту по собственному autoevent требует создания небольшого протокола подключений и отключений клиентов.

[Вад]

Dimka, я не про запись. Я про чтение: может ли писатель тоже читать из собственного пайпа (с выталкиванием)?

[Dimka]

Вад, наверно может. Только пока он будет подключен, не сможет подключиться читатель. Это ж не broadcast на много читателей, это point2point - именно из-за самого характера последовательного потока (а не файла с random access).

[sss]

Привет..

А если использовать SetWindowLong  GWL_USERDATA?

[sss]

Я тут почитал ссылку на топик - увидел своё сообщение 10 летней давности! Ввел IPC в впоисковике и нашел ссылку на MSDN и там пишут про WM_COPYDATA.. Что не работает такое сообщение ?

[zubr]

sss, не понял, каким боком для данной задачи SetWindowLong  GWL_USERDATA? Ну ладно передали мы в окно данные, а как уведомить это окно, что данные пришли? Все равно надо SendMessage посылать, или процесс окна должен опрашивать постоянно в цикле GetWindowLong  GWL_USERDATA, что есть криво. Что касается WM_COPYDATA - то да работать будет, позволит передавать блоки данных, а не просто число, но насколько я сталкивался с WM_COPYDATA - работает это сообщение медленно.

[Dimka]

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

С какой скоростью работает - не знаю. У меня оно только между разными instance одного процесса 1 раз срабатывало, когда новый instance обнаруживал предыдущий, пересылал ему свои параметры командной строки и на этом выключался. Тут real time не было.

[sss]

sss, не понял, каким боком для данной задачи SetWindowLong  GWL_USERDATA? Ну ладно передали мы в окно данные, а как уведомить это окно, что данные пришли? Все равно надо SendMessage посылать, или процесс окна должен опрашивать постоянно в цикле GetWindowLong  GWL_USERDATA, что есть криво. Что касается WM_COPYDATA - то да работать будет, позволит передавать блоки данных, а не просто число, но насколько я сталкивался с WM_COPYDATA - работает это сообщение медленно.

Обнулять например и проверять с необходимой  скоростью.. И почему криво - используя таймер перепроверять раз в 100 мс. При этом оставаться в одном и том же основном потоке.
Тут из контекста топикстартера - надо сделать как-нибудь не сложно и быстро.

...
Тут real time не было.

В смысле там ?  


Добавлю урл по теме

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574%28v=vs.85%29.aspx

[sss]

Ну и если есть проекты обоих приложений - можно использовать WriteProcessMemory/ReadProcessMemory по известным виртуальным адресам

[Джон]

ИМХО в дебри забрались. Может всё-таки выяснить чем прекрасно работающий с PostMessage вариант не нравится?