Выбор техники Linux IPC - PullRequest
Новая
       3

Выбор техники Linux IPC

2 голосов
/ 18 марта 2011

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

После прочтения имени исполняемого файла я создаю дочерний процесс, связываю исполняемый файл с моим модулем (который включает мою версию семейства функций malloc) и выполняю исполняемый файл, предоставленный пользователем. Родительский процесс будет состоять из графического интерфейса пользователя (с использованием инфраструктуры QT), где я хочу отображать предупреждения / ошибки / количество выделений.

Мне нужно сообщить количество mallocs / освобождает и серии предупреждающих сообщений в родительский процесс в режиме реального времени. После того, как приложение пользователя завершит выполнение, я хочу отобразить количество утечек памяти. (Я позаботился обо всем внутреннем кодировании, необходимом для этого, в общей библиотеке, с которой я ссылаюсь).

Real-Time:

У меня есть два разных подхода к передаче этой информации.

  1. Дочерний процесс записывает в 2 канала (1 для записи того, произошло ли выделение / освобождение, а другой для записи одного целого числа для обозначения предупреждающего сообщения).
  2. Я просто отправил сигнал, чтобы указать, произошло ли распределение. Также создайте сигналы для каждого из предупреждающих сообщений. Я сопоставлю их с фактическими предупреждениями (строками) в родительском процессе.

Является ли версия сигнала такой же эффективной, как использование трубы? Это возможно? Есть ли лучший выбор, так как я забочусь об эффективности:)

После того, как приложение пользователя завершит выполнение:

Мне нужно отправить всю структуру данных, которую я использую, чтобы отслеживать утечки памяти. Это может быть очень большим, поэтому я не уверен, какой метод IPC будет наиболее эффективным.

Спасибо за ваше время

Ответы [ 3 ]

3 голосов
/ 18 марта 2011

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

2 голосов
/ 19 марта 2011

Сигналы определенно не способ сделать это.Как правило, лучше всего избегать сигналов, когда это возможно.

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

1 голос
/ 19 марта 2011

Я предлагаю комбинацию разделяемой памяти и сокета. Имейте общую область памяти, скажем, 1 МБ, и записывайте всю свою информацию в каком-то стандартном формате в этот буфер. Если / когда буфер заполняется или процесс завершается, вы отправляете сообщение через сокет читателю. После ACK считывателя вы можете очистить буфер и продолжить.

Чтобы ответить на беспокойство caf по поводу повреждения целевого приложения, просто используйте системный вызов mprotect , чтобы удалить разрешения (установите PROT_NONE) из области общей памяти, прежде чем передать управление целевому процессу. Естественно, это означает, что вам придется устанавливать PROT_READ|PROT_WRITE перед обновлением журнала при каждом распределении, не будучи уверенным, что это выигрыш в производительности с добавленными вызовами mprotect.

РЕДАКТИРОВАТЬ: если это не очевидно, у вас может быть несколько буферов (или один разделен на N частей), чтобы вы могли немедленно передать управление целевому процессу и не ждать, пока читатель подтвердит ваш запрос. Кроме того, при наличии достаточных вычислительных ресурсов читатель может запускать столько раз, сколько ему нужно, для чтения текущего активного буфера и выполнения обновлений в реальном времени для пользователя или всего, для чего он читает.

...