Время ЦП конкретного дочернего процесса после первого вывода на стандартный вывод

Question

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

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

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

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

Спасибо:)

Answer 1

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

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

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

---

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