le bloc de contrôle du processus s'appelle aussi le contexte d’exécution du processus.
Disons que le bloc de contrôle du processus contient, indique le contexte processeur et mémoire du processus. Le contexte, c'est une notion abstraite, alors que le bloc de contrôle, c'est une notion concrète, puisqu'elle est présente dans la table des processus. Enfin, c'est comme ça que je le vois.
Citation
Dans la partie espace d'adressage d'un processus, tu a mit le "segment programme", le "segment de donnée" et la pile, mais où est le tas ? Et d’ailleurs, que comptes-tu mettre dans cette partie ? Parce que ça peut aller très loin.
Oui, je me suis également demandé ce que je compte mettre dans cette partie... Au départ, j'avais décidé d'introduire juste l'espace d'adressage, en disant que la pile descend vers le trou, que le code reste le même et les données montent quand il y a allocation dynamique. C'est tout. C'était juste pour en parler...
Citation
La partie ordonnancement et espace d'adressage pourrait être mise dans la partie présentation des processus. De même, tu pourrais regrouper dans cette partie tout ce qui est valable, même hors linux. Et déplacer le paragraphe commandes de gestion des processus sous unix un peu plus loin dans les parties suivantes.
Histoire de bien séparer ce qui est général à tous les OS et ce qui est particulier aux systèmes UNIX.
Bonnes idées, de toute façon je comptais réorganiser ce chapitre car à force d'ajouter des trucs par ci par là, eh bah on se retrouve avec un texte illisible.
EDIT: Par contre, juste une petite remarque sur la séparation UNIX/autres. Dans (presque) tous les systèmes, les processus ont des états. Or, moi, je présente le diagramme d'état des processus Unix. C'est un exemple, et cette séparation peut être problématique.
Tu pars loin desfois. Qu'est-ce que tu veux présenter, la programmation ou le système lui-même ?
Eh bien, c'est une question pleine de bon sens. Mais la programmation système passe par une bonne connaissance du système lui-même. C'est vrai que dans le chapitre sur les processus il y a beaucoup de théorie, mais il y en aura moins dans les chapitres suivants. En fait, la programmation système c'est pas vraiment compliqué du point de vue de la programmation (il suffit juste d'appeler la bonne fonction au bon moment, et de faire attention à ne pas tout abîmer...). La vraie problématique c'est de comprendre comment la machine exécute les appels-système, et que ce passe-t-il au niveau de l'OS... C'est vrai que pour cette révision du tuto, je suis parti sur des bases plus "théoriques", car j'ai eu quelques retours selon quoi on apprenait pas assez de choses, je n'expliquai pas tout. Eh bien ils vont être servis ! J'en parlerai au validateur pour savoir si c'est une bonne idée...
Up ?
Corrections orthographiques, syntaxiques, grammatiques, typographiques et ajout d'une sous-partie sur la terminaison des processus. Après une relecture rapide de cette dernière, je me demande si cela a sa place car on parle des programmes et non pas des processus, dans une partie de cette sous partie ( : p ). J'aimerais avoir vos avis à ce propos.
Ajout d'une sous-partie sur la terminaison des processus. Après une relecture rapide de cette dernière, je me demande si cela a sa place car on parle des programmes et non pas des processus, dans une partie de cette sous partie ( : p ). J'aimerais avoir vos avis à ce propos.
Je dirais que ça a sa place. Juste après la aprtie sur comment créer un processus, voici comment le finir, c'est bon. Et que ça soit valables aussi bien pour les programmes que pour les processus n'est pas un problème.
Nouvelle mise à jour du chapitre sur les processus. Il ne manque plus que l'exemple sur les macros status, que je testerai demain quand je retrouverai mon ordinateur.
Je cherche des commentaires, positifs voire négatifs ( ).
Je viens juste parler d'un sujet qui revient souvent en cours et qui serait intéressant je pense à ajouter au tuto. Tu fais un TP client/serveur, ca serait sympas un clientS/serveur. J'en parle car jai récemment eu le sujet et j'ai eu du mal à l'implémenter car ce n'est pas si simple qu'il y parait.
(http://www.siteduzero.com/forum-83-739815-p1-c-faire-un-dialogue-clients-serveur-avec-des-tubes-nommes.html#r7135272 : post que j'ai posté pour avoir de l'aide mais j'ai finalement réussi et mis le code final dans mon dernier post mais je pense qu'il est optimisable...c'est pourquoi j'aimerais voir la solution la plus "propre" de réaliser ce genre d'application.
En tout cas bravo pour ton tuto! Et courage pour la suite!
Découvre tout le background de leagueoflegends sur omégatheque ! Il y a même des vidéos sur les différents skins, des liens vers les streamers et webtvs les plus connus ! :D
Quand une application exécute un appel-système, elle peut alors effectuer un trap, et peut exécuter le code, du moment que le noyau le lui autorise.
L'ensemble de cette phrase ne m'a pas paru claire, d'autant que le lien wikipédia mène vers un contenu anglophone. Pourquoi ne pas faire référence au terme plus courant (il me semble) "exception" ?
Cette fonction affiche sur stderr (sortie d'erreur standard) une représentation en une chaîne de caractère de l'erreur décrite par errno, précédée par la chaîne de caractère pointée par s ainsi que d'un espace.
Un simple exemple d'affichage de cette fonction perror() éclaircirait grandement tes propos.
Si l'utilisateur indique au noyau le programme initial à exécuter, celui-ci tente alors de le faire avec quatre exécutables, dans l'ordre suivant : /sbin/init, /etc/init puis /bin/init.
Tu en cites trois, pas quatre.
Citation
Il existe une permission spéciale, uniquement pour les exécutables binaires, appelée la permission Set – UID. Cette permission permet à l'utilisateur ayant les droits d'exécution sur ce fichier d'exécuter le fichier avec les privilèges de son propriétaire. On met les droits Set - UID avec la commande chmodet l'argument +s. On passe en second argument le nom du fichier.
Elle n'est pas unique il en existe 3 :
Citation : Référence Debian
Il existe trois bits qui donnent des permissions particulières :
le bit set user ID (s ou S situé à la place du x) de l’utilisateur ;
le bit set group ID (s ou S situé à la place du x) du groupe ;
le bit collant « sticky bit » (t ou T situé à la place du x) des « autres ».
Tu regroupes la première et la seconde en omettant leurs noms (set - ID), mais elles n'ont pas le même effet :
Citation : Référence Debian
Définir set user ID sur un fichier exécutable permet à un utilisateur d'exécuter les fichier avec l’identifiant du propriétaire du fichier (par exemple root).
De la même manière, définir set group ID sur un fichier exécutable permet d'exécuter le fichier avec l’identifiant de groupe du fichier (par exemple root).
Citation
$ ls -l
total 4
-rw-r--r-- 1 lucas lucas 290 2010-12-01 15:39 zombie.sh
$ chmod +s zombie.sh
$ ls -l
total 4
-rwSr-Sr-- 1 lucas lucas 290 2010-12-01 15:39 zombie.sh
Cet exemple est incorrect.
Le fichier dont tu te sers dans l'exemple n'est pas un exécutable, du coup la permission spéciale n'est pas activée (le S majuscule le précise).
Pour coller avec tes explications, la commande chmod dans l'exemple devrait donner ce droit seulement à l'utilisateur : $ chmod u+s
Tu pourrais aussi préciser que les permissions spéciales sont "dangereuses" :
Citation : Référence Debian
Parce que ces positionnements de bits peuvent créer des risques de sécurité, il ne faut les activer qu'avec des précautions extrêmes.
Bon nombre de fonctions utilisées avec la programmation système (notamment les appels-système) nécessiterons l'inclusion de la bibliothèque <unistd.h>. Donc, pensez bien de mettre, au début de vos fichiers : #include <unistd.h>
On dit inclusion de header, fichier d'entête, ou interface de bibliothèque, mais pas de bibliothèque tout court.
Citation
Je finis sur un dernier Warning avant de nous quitter pour ce deuxième chapitre : attention à ne pas placer fork dans des boucles infinies (évitez de le mettre dans une boucle tout court d'ailleurs...). En effet, il n'y a aucune sécurité sur le système : imaginez un peu le désastre si vous vous créiez des milliers de processus...
Alors pourquoi employer une boucle dans ton exemple de code, qui sera forcément réutilisé ?
Il y a un souci sur cette phrase, voir le mot en gras :
Citation
Pour y remédier, il est préférable d'utiliser la macro assert, déclarée qui fonctionne comme suit.
Tous tes tests de retour sur la fonction atexit if(atexit(routine)==-1) sont à remplacer par if(atexit(routine)!=0) :
Citation : man atexit
VALEUR RENVOYÉE
La fonction atexit() renvoie 0 en cas de succès et une valeur non nulle en cas d'échec.
Idem pour la fonction on_exit :
Citation
Elle renvoie 0 en cas de réussite ou -1 sinon.
Citation : man on_exit
VALEUR RENVOYÉE
La fonction on_exit() renvoie 0 si elle réussie ; sinon elle renvoie une valeur non nulle.
Citation
/* La fonction father_process effectue les actions du processus père */
void father_process(int child_pid)
{
printf(" Nous sommes dans le père !\n"
" Le PID du fils est %d.\n"
" Le PID du père est %d.\n", (int) child_pid, (int) getpid());
/* ... */
}
Le cast en int de la variable child_pid est inutile car c'est déjà un int.
Par contre, si le paramètre effectif de father_process() est un pid_t, il faut le caster en int, ce qui n'est pas fait dans le main :
Citation
int main(void)
{
pid_t pid = create_process();
/* ... */
father_process(pid); // Ici il faut un cast en int
/* ... */
}
Il faudrait rajouter dans la partie sur les FIFO que l'appel à open en lecture est bloquant jusqu'à ce qu'il y ait un appel à open en écriture, et comment créer des FIFO non bloquants car ça peut être utile si on veut créer un serveur qui attend des ordres via fifo, dont les clients ne sont pas connectés lors du lancement du serveur.
Un bon tuoriel pour comprendre les processus , les threads , les tubes dans moins de 4 heures , faut juste ajouter un peu plus d'explications pour bien coller les infos
Merci pour le tuto. Malgré quelques imperfections ici et là, c'est une ressource en Français très sympa pour qui veut en apprendre plus sur la programmation système sur Linux ou tout simplement mettre en pratique la théorie de cours sur le temps réel, l'ordonnancement.
Si on avait pu faire ça en cours (le côté pratique), je pense qu'on aurait été un peu plus de deux a suivre..
Une remarque que je me permet de faire pour tout ceux qui, comme moi, ont bugé sur le pthread_cond_wait:
Personnellement je ne comprenais pas comment ca faisait pour fonctionner (exemple alarme -compteur) dans le sens où on bloque le mutex avec pthread_mutex_lock puis on attend la condition (compteur supérieur à x) avec pthread_cond_wait ...et du coup... comment le compteur fait il pour donner le signal de condition puisqu'il a besoin de locker le mutex quand on atteint X ...
J'ai trouvé la réponse ici et pensé que ça pourrait intéresser qqun (notamment l'auteur qui pourrait l'expliquer dans le cours par exemple )
Tout d'abord, merci pour le tuto. Je crois qu'il y a une erreur dans le chapitre sur les tubes, sur l'exemple des permissions :
" Bon, un petit exemple, parce que je sens que vous n'avez pas tout compris ( ) : Pour attribuer toutes les permissions à vous, seule la lecture pour le groupe, et aucune pour les autres, la valeur correspondante est 0720 (Premier chiffre = 0 (obligatoire) ; Deuxième chiffre = 1 (Exécution) + 2 (Ecriture) + 4 (Lecture) ; Troisième chiffre = 0 (aucune permission))."
Pour avoir toutes les permissions pour soi, la lecture pour le groupe et aucune pour les autres, c'est 0740 (Premier chiffre = 0 (obligatoire); Deuxième chiffre = 1 + 2 + 4 = 7 (execution + ecriture + lecture); Troisième chiffre = 4 (lecture seule); Quatrième chiffre = 0 (aucune permission); )
Il y a aussi un petit oubli, il y a 4 chiffres, mais 3 seulement sont détaillés (la lecture a été oubliée).
Avant de poster un message, vérifiez la date du sujet dans lequel vous comptiez intervenir.
Si le dernier message sur le sujet date de plus de deux mois, mieux vaut ne pas répondre. En effet, le déterrage d'un sujet nuit au bon fonctionnement du forum, et l'informatique pouvant grandement changer en quelques mois il n'est donc que rarement pertinent de déterrer un vieux sujet.
Au lieu de déterrer un sujet il est préférable :
soit de contacter directement le membre voulu par messagerie privée en cliquant sur son pseudonyme pour accéder à sa page profil, puis sur le lien "Ecrire un message"
soit de créer un nouveau sujet décrivant votre propre contexte
ne pas répondre à un déterrage et le signaler à la modération
Je ferme ce sujet. En cas de désaccord, me contacter par MP.
Donatien