J'ai une tâche qui traite une liste de fichiers sur stdin. Le temps de démarrage du programme est important et le temps nécessaire à chaque fichier varie considérablement. Je veux générer un nombre important de ces processus, puis envoyer le travail à ceux qui ne sont pas occupés. Il existe plusieurs outils de ligne de commande différents qui font presque ce que je veux, je l'ai réduit à deux options presque opérationnelles:
find . -type f | split -n r/24 -u --filter="myjob"
find . -type f | parallel --pipe -u -l 1 myjob
Le problème est que cela split
fait un round-robin pur, donc l'un des processus prend du retard et reste en arrière, retardant la fin de l'opération entière; tandis que parallel
veut générer un processus par N lignes ou octets d'entrée et je finis par passer trop de temps sur les frais généraux de démarrage.
Y a-t-il quelque chose comme ça qui réutilisera les processus et les lignes d'alimentation vers les processus qui ont débloqué les stdins?
myjob
est prête à recevoir plus de commentaires. Il n'y a aucun moyen de savoir qu'un programme est prêt à traiter plus d'entrée, tout ce que vous pouvez savoir, c'est qu'un tampon quelque part (un tampon de canal, un tampon stdio) est prêt à recevoir plus d'entrée. Pouvez-vous arranger votre programme pour envoyer une sorte de demande (par exemple afficher une invite) quand il est prêt?
read
appels ferait l'affaire. C'est un effort de programmation assez important.
-l 1
dans les parallel
arguments? IIRC, qui indique en parallèle de traiter une ligne d'entrée par tâche (c'est-à-dire un nom de fichier par fork de myjob, donc beaucoup de frais généraux de démarrage).
split
commande? Le nom est en conflit avec l' utilitaire de traitement de texte standard .