Время ЦП конкретного дочернего процесса после первого вывода на стандартный вывод - PullRequest
4 голосов
/ 11 января 2012

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

Однако этот подход обеспечивает общее время, потраченное конкретным дочерним процессом, и меня интересует только количество времени, потраченное после определенного события, а именно первый вывод дочернего процесса в stdout , Я рассмотрел другие способы получения процессорного времени дочерних процессов, такие как getrusage (2) и times (3), но кажется, что они не способны различать время нескольких дочерних процессов, а вместо этого предоставляют сумма времени всех дочерних процессов.

Я работаю над приложением текстового редактора, которое позволяет пользователям запускать скрипты и код на разных языках, а в приложении есть встроенная функция синхронизации кода. Приложение использует скрипты bash для запуска пользовательского кода, и первое, что делают мои скрипты bash, - это вывод байта начала заголовка (0x02). После этого скрипт bash делает все, что нужно для запуска пользовательского кода, и это то, на что я хочу рассчитывать. Bash может выполнить небольшую инициализацию (для настройки переменных PATH и т. Д.), Что может занять 30 или 40 мсек, и я не хочу, чтобы эта инициализация была синхронизирована с остальными. Если пользовательский код является, например, простой программой типа Hello World на C, функция синхронизации может отображать что-то вроде 41 мс вместо фактической 1 мс, которая потребовалась для запуска их кода.

Есть идеи, как это можно сделать?

Спасибо:)

1 Ответ

3 голосов
/ 11 января 2012

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

Первое - это избавиться от сценариев bash и просто выполнить эквивалентную работу в вашей программе перед запуском кода пользователя (например, между fork() и exec()). Таким образом, время процессора дочернего процесса от wait4() не включает ваши дополнительные настройки.

Другая возможность - написать простое приложение, которое не выполняет ничего, кроме запуска приложения пользователя и сообщает о времени своего процессора вашему основному приложению. Это приложение для запуска может затем вызываться из ваших сценариев для запуска программы пользователя, а не для непосредственного вызова программы пользователя. Приложение запуска может само использовать fork() / exec() / wait4() для запуска программы пользователя и может сообщать информацию из wait4() в вашу основную программу с помощью любого из множества средств, таких как именованный канал, сообщение очередь, сокет или даже просто запись информации в файл, который ваша основная программа может открыть позже. Таким образом, ваши bash-скрипты могут работать как до, так и после запуска пользовательской программы, которая не будет включена в процессорное время, сообщаемое приложением бегуна. Вы, вероятно, захотите, чтобы бегун принял аргумент, такой как имя канала или выходной файл, в дополнение к пути и аргументам пользовательской программы, чтобы вы могли контролировать, как сообщается информация - таким образом, вы можете запустить более одного экземпляр приложения Runner и по-прежнему хранит информацию, которую они сообщают отдельно.


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

...