je passe à la repêche un examen de programmation système (demain matin 8h30...)
Ah, ouais ! quand même ! :-)
2/Une ecriture sur un tube sans lecteurs en mode bloquant provoque l'envoi du signal SIGPIPE au processus ecrivain, même si celui-ci a la place d'ecrire dans le tube.
Vrai (pas sur)
Non. C'est même à cela que servent les tubes nommés. A se donner rendez-vous de manière asynchrone. Par contre, il y a des chances de se prendre un SIGPIPE si le lecteur REFERME son handler.
3/ Un processus n'effectuant aucun appel systeme n'est pas interruptible par un signal, car les signaux ne sont délivrés que lors du passage en mode noyau.
Faux (on peux toujours envoyer un kill -9)
Pas seulement. Même si tu fais un while(1);, ton processus pourra être préempté ! C'est à ça que servent les signaux. Et c'est pour cela que l'on peut faire un Ctrl-C dessus.
4/ La terminaison d'un processus provoque la terminaison de tous ses fils. Vrai (quoique vérifie dans quel cas il passe zombi et dans quel cas il quitte proprement)
Oui, c'est vrai, mais le processus peut prendre les devants pour s'émanciper. Par contre, cela n'a rien à voir avec les zombies, qui sont des processus morts mais qui ne peuvent être incinérés avant que le père n'ait reconnu le corps.
6/ En terme d'espace disque, la création réussie d'un lien physique (par le shell: ln titi toto ou par l'appel link) est plus coûteuse que la création réussie d'un lien symbolique.
Vrai (12 octet contre 14k pour le lien physique)
Quoi ? O_O
1/Expliquer pourquoi il est en général préférable d'utiliser les fonctions d'entrées-sorties de haut niveau plutot que celle de bas niveau? Meilleur perf, meilleures possibilité donnée au compilo pour optimiser le tout.
Pas le compilateur, mais le système lui-même. En particulier, on permet au processus de rester en userland le maximum du temps et de limiter les appels au noyau.
2/ Qu'est-ce qu'une fonction réentrante? Illustrer sur un exemple le type de problème que peut poser l'utilisation de fonctions non réentrantes.
Si mes souvenirs sont bon, c'est une fonction qui repartira au même endroit si elle a été interrompue par un signal.
Non. C'est une fonction qui, sans être explicitement récursive, sera quand même directement ou indirectement dépendante d'elle-même, ce qui fait qu'elle se mordra la queue. Exemple à la con :
int fprintf (FILE * f, char * message)
{
if (f) /* Fichier ouvert ? */
{
Ecrire message
}
else fprintf (stderr,"Erreur : fichier non ouvert");
}
3/ Quelle différence y'a-t-il entre attente active et attente passive? Donner un exemple de chacune des deux.
Dans quel contexte ?
sleep (attente passive)
select(attente active)
Non plus. Ces deux fonctions sont toutes les deux passives et attendent le feu vert du système pour se réveiller. Une attente active est lorsque l'on provoque soit même une temporisation, ou bien lorsqu'on boucle bêtement en attendant qu'une condition soit remplie :
while (!feu_vert); /* Attend le bon moment */.
Pas la peine de dire que le programme en question va bouffer 100% du CPU.
1/ Quels appels systèmes ou bibliothèque pourrait-on utiliser pour ecrire un programme dont le lancement équivaut à ls rep? Quels sont les permissions nécessaire pour que cette commande réussise?
getdents()
man getdents :
This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface. This page documents the bare kernel system call interface.
3/ Que peut-on en déduire pour les permissions positionnées sur le répertoire rep?
Je vois pas comment c'est possible.
Parce que si il peux lister c'est qu'il a les droits x (traverser le répertoire) et r (lire la liste des fichiers)
Et ls -l donnera la liste de ces mêmes fichiers avec un descriptif long.
Essaie chmod 111 rep, c'est marrant.
Les gars ! relisez-vous un peu, quoi. C'était pour un exam !
[^] # Re: Réponse (a vérifier)
Posté par Obsidian . En réponse au message Questions d'exam. Évalué à 2.
Ah, ouais ! quand même ! :-)
Non. C'est même à cela que servent les tubes nommés. A se donner rendez-vous de manière asynchrone. Par contre, il y a des chances de se prendre un SIGPIPE si le lecteur REFERME son handler.
Pas seulement. Même si tu fais un while(1);, ton processus pourra être préempté ! C'est à ça que servent les signaux. Et c'est pour cela que l'on peut faire un Ctrl-C dessus.
Oui, c'est vrai, mais le processus peut prendre les devants pour s'émanciper. Par contre, cela n'a rien à voir avec les zombies, qui sont des processus morts mais qui ne peuvent être incinérés avant que le père n'ait reconnu le corps.
Quoi ? O_O
Pas le compilateur, mais le système lui-même. En particulier, on permet au processus de rester en userland le maximum du temps et de limiter les appels au noyau.
Non. C'est une fonction qui, sans être explicitement récursive, sera quand même directement ou indirectement dépendante d'elle-même, ce qui fait qu'elle se mordra la queue. Exemple à la con :
int fprintf (FILE * f, char * message)
{
if (f) /* Fichier ouvert ? */
{
Ecrire message
}
else fprintf (stderr,"Erreur : fichier non ouvert");
}
Non plus. Ces deux fonctions sont toutes les deux passives et attendent le feu vert du système pour se réveiller. Une attente active est lorsque l'on provoque soit même une temporisation, ou bien lorsqu'on boucle bêtement en attendant qu'une condition soit remplie :
while (!feu_vert); /* Attend le bon moment */.
Pas la peine de dire que le programme en question va bouffer 100% du CPU.
man getdents :
This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface. This page documents the bare kernel system call interface.
Essaie chmod 111 rep, c'est marrant.
Les gars ! relisez-vous un peu, quoi. C'était pour un exam !