IPC между приложением python и внедренной DLL

Привет, переполнение стека: иногда читатель, первый раз постер.

Предыстория:

Коробка Windows с XP SP3, которая скоро будет обновлена ​​до Windows Seven (MSDNAA ‹3)

У меня есть внедренная DLL, которая получает циклы, перехватывая функцию, которая вызывается тысячи раз в секунду.

Я хотел бы общаться/управлять этой DLL через приложение Python. По сути, DLL делает всю работу, а приложение python обеспечивает мозги/принятие решений.

Мой план игры для этого состоит в том, чтобы иметь счетчик и оператор if в DLL. Каждый раз, когда вызывается перехваченная функция, counter++ и затем возвращаются к исходной функции до тех пор, пока не произойдет что-то вроде if ( counter == 250 ) { // dostuff(); }. Мое мнение, что это позволит целевому приложению работать в основном беспрепятственно, но все же позволит мне делать интересные вещи.

Проблема:

Я в полной растерянности, какой метод IPC мне следует использовать для связи. У нас есть сокеты, разделяемая память, каналы, отображение файлов (?), RPC и другие (на первый взгляд) эзотерические вещи, такие как запись в буфер обмена.

Я НИКОГДА не реализовывал какие-либо IPC, кроме игрушечных примеров.

Я совершенно уверен, что мне нужно что-то, что:

  • Может поддерживать обмен данными между Python и DLL.
  • Не блокирует/ждет
  • Можно проверить наличие ожидающих данных и продолжить, если их нет.
  • Если задействованы блокировки, можно продолжить вместо ожидания
  • Не требует много времени для чтения/записи.

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

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


python ipc code-injection dll
person Horace Blegg    schedule 12.01.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Попробуйте сокеты. Ваши требования по существу являются требованием асинхронной работы; В Python есть модуль asyncore для асинхронного ввода-вывода на сокетах. В то же время не похоже, что stdlib Python может асинхронно обрабатывать другие вещи IPC, поэтому я бы не рекомендовал их использовать.

person ulidtko    schedule 20.01.2011

arrow_upward
1
arrow_downward

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

person Apalala    schedule 07.01.2011
comment
Использование файла журнала не вообще не является IPC. - person ulidtko; 20.01.2011
comment
@ulidtko Файловая система — самая старая и самая надежная форма синхронизации IPC. Вот почему стандарт POSIX имеет одинаковый API для всех форм IPC. Поскольку ОС должна обеспечивать согласованность и синхронизацию в операциях файловой системы (или не называться ОС), файловая система является самой простой реализацией IPC для использования в программах, не относящихся к ОС. Попробуйте ls /var/run/*.pid в следующий раз, когда у вас будет доступ к системе *nix. - person Apalala; 21.01.2011
comment
Печать — еще более старый и надежный способ... хранения информации на бумаге. ОС должна обеспечивать согласованность того, что будет напечатано, и любой человек может сам управлять всей необходимой синхронизацией. Почему бы вам не попробовать распечатать Hello world! на бумаге, а затем сканировать и распознавать его для управления вашей программой? Извините, но ваш комментарий - не просто аргумент. Принтеры должны печатать документы, файловые системы должны хранить файлы, shmem-pipes-sockets должны обеспечивать способы выполнения IPC. - person ulidtko; 21.01.2011