Como saber que a aplicação terminou de processar o arquivo?
estou a tentar automatizar a instrumentação que estou a fazer na aplicação, mas o problema é que estou a lidar com aplicações que não saem sozinhas após o processamento. Por exemplo, tome qualquer pdfviewer/reader, Se eu abrir um arquivo o arquivo é exibido e eu posso ver que a aplicação processou o arquivo.
ao processar o ficheiro pela aplicação, o que quero dizer é que o ficheiro foi exibido com sucesso pela aplicação.
A aplicação pode ser qualquer interface gráfica visualizador de pdf para ex adobe reader, xpdf, foxitreader ou qualquer visualizador de imagens para ex gpicview, etc. Formatos de arquivos podem ser de qualquer tipo e não qualquer formato de arquivo específico.
também Não tenho o código fonte de uma aplicação, estou lidando com binário da aplicação.
mas ao automatizar o processo, quero saber quando a aplicação processou o ficheiro. O que eu posso pensar inicialmente é que haveria alguns blocos básicos que dizem que depois que ele é executado ele terminou de processar o file e saia da minha instrumentação quando o bloco básico em particular tiver sido executado.
Mas o problema aqui é como identificar esse bloco básico ?1 answers
Provavelmente a coisa mais fácil e mais confiável que você pode fazer automaticamente para executáveis de caixa preta é olhar para a sua utilização de CPU. Quando terminam de carregar, todos os seus fios devem estar (na sua maioria) ociosos, talvez acordando ocasionalmente se esperarem por eventos com um tempo-limite não-infinito. (E de diversos eventos GUI como o movimento do mouse).
Certifique-se que espera o tempo suficiente para detectar a diferença entre bloqueados no disco I/O vs. bloqueados à espera da entrada do utilizador. (Nos sos do tipo Unix, esta é a diferença entre o sono em disco e o sono, como mostrado por D vs. S em coisas como a lista de processos de top.)
Se não quiser contar com o SO para detectar o sono em disco versus o sono regular, espere algumas vezes mais do que o tempo máximo de serviço de pedido de E/S do disco (~= algumas vezes latência do disco, menor se o processo em teste for o único processo a fazer I/O). Se o processo de caixa preta não tiver usado nenhum tempo de CPU nesse intervalo, você pode assumir que acabou de carregar e está exibindo o arquivo na tela.
Claro que, como @Ped7g aponta, pode não ter analisado todo o ficheiro. Ele pode carregá-lo preguiçosamente, a pedido, como o usuário scrolls através de um grande PDF, por exemplo. Observar o tempo de CPU deve ser uma forma razoável de detectar quando um processo terminou de atualizar após o envio programático de um comando page-down.
Acho que deves conseguir bons resultados de confiança com isto. Você pode precisar de uma heurística que considere múltiplas entradas, como o desempenho do sistema I / O ou pedidos de Disk-IO pendentes, se você quiser decidir de forma confiável que um processo é feito de carregamento sem esperar tanto quanto o pior caso possível.Tal como discutido nos comentários, procurar o processo para chegar a EOF num descritor de ficheiro não é fiável para este fim (pode fazê-lo desaparecer). Vou deixar isto aqui no caso de ser interessante ou útil para alguém, mas para o seu uso, talvez queira ignorar isto completamente. Na melhor das hipóteses, podes usar isto. como uma entrada para o seu heuristic para decidir quando um processo é feito carregar.
Na maioria das eo, existem algumas facilidades para processos de rastreamento de outros processos. No Linux, o principal é a API do ptrace. Comandos como ostrace usam-no para rastrear as chamadas do sistema. Acredito que o Windows tem algo semelhante, e presumo que o OS X também.
Assim você pode procurar o open () System call on the PDF para encontrar o fd direito, em seguida, procurar por mmap, read (), e close() sistema chama sobre ele. O If read () devolve 0, é na EOF. Se estiver fechado sem mmap, o processo é feito com ele (a menos que ele o abra novamente, ou usado dup() ou dup2() por alguma razão).
Podes analisar a saída de texto do strace, ou usar a API do ptrace sozinho.
Em alternativa, no Linux poderá ver a posição do ficheiro em /proc/<PID>/fdinfo/<FD>. Outros SOs provavelmente têm recursos semelhantes para ver a posição de arquivo de descritores / arquivos abertos.
Por exemplo, acontece que tenho evince open exibindo um PDF. In ' / 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