Как узнать, что приложение завершило обработку файла?

Question

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

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

Приложение может быть любым графическим редактором PDF для ex adobe reader, xpdf, foxitreader или любого средства просмотра изображений для ex gpicview и т. Д. Форматы файлов могут быть любого типа, а не определенного формата файла.

Также у меня нет исходного кода приложения, я имею дело с двоичным кодом приложения.

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

Но проблема в том, как определить этот базовый блок?

Answer 1

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

Убедитесь, что вы достаточно долго ждали, чтобы обнаружить разницу между заблокированными дисковыми вводами/выходами и заблокированными в ожидании ввода пользователем. (В Unix-подобных операционных систем, это разница между дисками сна и сна, как показано D VS. S в такие вещи, как список процессов top «s.)

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

Конечно, поскольку @ Ped7g указывает, возможно, он не проанализировал весь файл. Он может загружать его лениво, по запросу, поскольку пользователь прокручивает большой PDF-файл, например. Наблюдение за временем процессора должно быть разумным способом обнаружить, когда процесс завершил обновление после программной отправки его команды вниз.

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

---

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

В большинстве ОС есть некоторые возможности для процессов отслеживания других процессов.В Linux основным является API ptrace. Такие команды, как strace, используют его для отслеживания системных вызовов. Я считаю, что Windows имеет нечто подобное, и я предполагаю, что OS X тоже.

Таким образом, вы можете найти системный вызов open() в PDF, чтобы найти правильный fd, затем найдите системные вызовы mmap, read() и close(). Если read() возвращает 0, он находится в EOF. Если он закрыт без mmap, процесс выполняется с ним (если он не откроет его снова или не использует dup() или dup2() по какой-либо причине).

Вы можете проанализировать вывод текста strace или использовать API ptrace самостоятельно.

---

Кроме того, на Linux вы можете посмотреть на позицию файла в /proc/<PID>/fdinfo/<FD>. Другие ОС, вероятно, имеют аналогичные возможности для просмотра позиции файла открытых файловых дескрипторов/дескрипторов файлов.

Например, у меня есть evince с отображением PDF. В `/ Proc/

$ ll /proc/4241/fd 
... 
lr-x------ 1 peter peter 64 Oct 21 06:43 14 -> /f/p/docs/agner_fog.microarchitecture.pdf # is anyone really surprised this is the PDF I had open? :P 
... 
$ ls -lL /proc/4241/fd/14  # follow the symlink to see the file size 
-rw-rw-r-- 1 peter peter 2078709 Feb 4 2016 /proc/4241/fd/14 

$ m /proc/4241/fdinfo/14  # alias for less 
pos: 2078709 
flags: 0100000 
mnt_id: 49 

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