sur une plate-forme intégrée (sans partition de swap), j'ai une application dont le processus principal occupe la plus grande partie de la mémoire physique disponible. Le problème est que je souhaite lancer un script externe de Shell à partir de ma demande, mais utiliser Fork () exige qu'il y ait suffisamment de mémoire pour 2x mon processus d'origine avant le processus d'enfant (qui sera finalement exécuté à quelque chose de beaucoup plus petit) peut être créé) .
Voilà donc un moyen d'invoquer un script shell à partir d'un programme C sans encourir la mémoire de la mémoire d'une fourchette ()?
J'ai envisagé de contours de contournement, comme ayant un processus plus petit secondaire qui est responsable de la création de coques, ou d'avoir un script "surveillant" que je signale en touchant un fichier ou un somesuch, mais je préfère avoir beaucoup plus de simples. < / p>
5 Réponses :
Si votre système a un MMU, alors généralement Si vous savez que vous n'avez pas de MMU, alors peut-être que Fork () est implémenté à l'aide de Copy-On-Write, qui n'alloit pas réellement plus de mémoire à l'heure Fourche () est appelé. La mémoire supplémentaire ne serait attribuée que si vous écrire à l'une des pages partagées avec le processus parent. Un EXEC () jetterait ensuite ces pages.
Fork () est bien implémenté à l'aide d'une copie réelle. Une autre approche pourrait être d'avoir un processus d'assistance responsable des subventions de frai, que vous communiquez avec l'utilisation d'un tuyau.
J'ai testé cela sur un système Normal Linux 2.6 qui configuré avec aucune partition de swap. Lorsque mon processus de parent est d'environ 300 MEGS, je constate que j'ai besoin d'au moins 200 Mo de mémoire libre, comme indiqué au sommet afin d'utiliser Fork (). Tout de moins et cela renvoie une erreur. Je pense que la vache ne se produit que si vous avez une partition de swap qui permet à Linux croire que, même si cela n'a pas à copier les pages avant d'écrire, cela pourrait si vous le faites.
Je pense que cela dépend de la manière dont Overgommit est mis en place. Linux fait toujours une vache, mais elle compte les pages contre la machine virtuelle disponible et l'échouera si le résultat dépasserait la mémoire virtuelle (au cas où ces pages sont ensuite modifiées et doivent être copiées). Avoir un échange, il suffit de prendre en compte le noyau de considérer la machine virtuelle disponible.
Il sonne comme si le mouvement prudent dans ce cas est de porter votre script shell (si possible) à c et l'exécutant dans le processus; Donc, vous n'avez pas à la fourche du tout.
à nouveau; Je ne sais pas ce que vous essayez réellement de faire .
Au lieu de forcer votre processus pour frayer une coquille, lancez une coquille dans votre processus (au premier plan), puis la fourchez dans la coque.
/bin/ash /scripts/propertask &
Je pense que vous pouvez trouver que le système est mis en œuvre comme Fork / EXEC / WAIT, qui vous donnera le même problème que la question recherchée à résoudre.
Paxdiablo est correct, système () utilise la fourchette () en interne. Le manifestation de la page de l'homme le mentionne obliquement: "... p. Ex. Fork () a échoué ...": Linux.die.net/man/3/System
Je vois que vous avez déjà accepté une réponse, mais vous voudrez peut-être lire sur http://www.opengroup.org/onlinePubs/9699919799/fonctions /posix_spawn.html posix_spawn et utiliser si elle est disponible sur votre cible:
Voir la réponse de Greg Hewgill ci-dessous. Ceci est un peu dépendant de la plate-forme - Pourriez-vous s'il vous plaît élaborer sur quelle plate-forme que vous utilisez (par exemple a-t-elle un MMU?)
N'est-ce pas une dupe d'une question posée hier ?? Stackoverflow.com/Questtions/2731531 / ...
Oui et non, @pavel, celui-ci n'est pas spécifique à Linux et il a des informations supplémentaires sur ce qui est exécuté - un script shell. L'autre intervenant a peut-être eu la possibilité de réécrire leur application à utiliser des threads (si le programme EXECD était exécutable sous leur contrôle plutôt que Bash / ksh / autre-shell) mais probablement pas dans ce cas.
@paxdiablo, OK, donc si ce n'est pas une dupe, que je ne peux répondre à cette question aussi ... mais avec la même réponse. Comment venir?
"Dois-je écrire mon serveur Web à Cobol?" et "devrais-je écrire mon package de comptabilité à Assembleur?" Aussi avoir la même réponse (un "non !!") mais ce sont des questions très distinctes, même si elles sont à la fois une forme "devrais-je choisir une langue inappropriée pour développer ma demande? ". Je soutiens que la "duppiosité" est une propriété de la question, pas la réponse. En tout état de cause, même pensé que la réponse vous peut donner est la même, cela ne signifie pas que l'ensemble des réponses possibles est identique. Exemple: sous Linux, VFORK n'a aucun avantage, pas pour de nombreux UNIXES.
@paxdiablo, oh, c'est Unix ... je suis trop utilisé pour le lire comme "Linux".