Reprise du message précédent :

Le 24 novembre 2004 - 13 h 30, bernie38 a écrit : et remarque le "laisserFinirLEnfant" et le commentaire qui va avec (ça te rappelle rien ? )

Heu... rafraichit moi la memoire?

Ah, au fait, dans google j'ai mis pipe C : sans le C, je suis sur que ça m'aurait donné d'autres résultats moins... pertinents, quoique un peu plus ludiques

Le 24 novembre 2004 - 13 h 32, Woofy a écrit : Le 24 novembre 2004 - 13 h 30, bernie38 a écrit : et remarque le "laisserFinirLEnfant" et le commentaire qui va avec (ça te rappelle rien ? ) Heu... rafraichit moi la memoire?

tu avais pas un engorgement ? un truc qui avait pas le temps de tout avaler (:rougir: pourtant tu utilises pas les pipes), des caractères qui se perdaient ?

Si!
La oui je vois!

Le 24 novembre 2004 - 13 h 33, bernie38 a écrit : Ah, au fait, dans google j'ai mis pipe C : sans le C, je suis sur que ça m'aurait donné d'autres résultats moins... pertinents, quoique un peu plus ludiques

Bah tu sais quand tu travail sur les bits, les pipes, forcement ca fait jaser!

Tout etant quasiment des fichiers sur *nix, c'est un peu con ....

Il y a une liste exhaustive de ce qu'on ne peut utiliser ?

Ca compile pas sous alpha!
Et le pire, c'est que je sais pas pourquoi!

Le 24 novembre 2004 - 16 h 48, iraysyvalo a écrit : Tout etant quasiment des fichiers sur *nix, c'est un peu con .... Il y a une liste exhaustive de ce qu'on ne peut utiliser ?

Disons que je peut tout utiliser, tant que je le recode moi meme!
Mais si y a besoin d'une fonction qui est impossible a recoder avec les instructions de base, c'est meme pas la peine d'essayer.

kill et signal sont des instructions de base ???

Et c'est ou ton pb de compil ? Bref, c'est tres chiant car comme tu utilises des fonctions recodees comme tu dis (tes my_*, je suppose) il est dfficile de reproduire tes bugs et tout ca ..

Pour archiver man tar .. pour compresser, man bzip2 ou gz, pour envoyer en ftp, man ftp ou man yafc ..

Bon ben en fait c'etait des problemes de lib.

Bon, ca compile sans warning sur les 3 archi, ca marche sur NetBSD, ca marche sur alpha, mais j'ai une segfault aleatoire sur Sun, parfois (genre je le lance 50fois ca passe, la 51eme passe plus, je relance ca plante au bout de la 40eme, ...)

Bizzare ??

Le 24 novembre 2004 - 17 h 27, Woofy a écrit : Bon ben en fait c'etait des problemes de lib. Bon, ca compile sans warning sur les 3 archi, ca marche sur NetBSD, ca marche sur alpha, mais j'ai une segfault aleatoire sur Sun, parfois (genre je le lance 50fois ca passe, la 51eme passe plus, je relance ca plante au bout de la 40eme, ...) Bizzare ??

Non, pas bizarre, mais UB et oui, c'est un grand standard, l'UB hélas... On le retrouve à tous les coins de rue, décidemment. Faudrait "encadrer" l'endroit où ça plante, si possible.

Le 24 novembre 2004 - 17 h 27, Woofy a écrit : Bon ben en fait c'etait des problemes de lib. Bon, ca compile sans warning sur les 3 archi, ca marche sur NetBSD, ca marche sur alpha, mais j'ai une segfault aleatoire sur Sun, parfois (genre je le lance 50fois ca passe, la 51eme passe plus, je relance ca plante au bout de la 40eme, ...) Bizzare ??

Je rappelle que les signaux dependent des architectures

alors ce serait du "pas portable" ? et pour le comportement "aléatoire", alors ?

http://www.enseignement.polytechnique.fr/profs/informatique/Didier.Remy/system/camlunix/sign.html

http://www-gtr.iutv.univ-paris13.fr/Cours/Mat/Systeme/CoursUnixGTR/chap-10_chap-10.html

Vous noterez qu'apparemment le traitement des signaux est différent suivant la version Nix (BSD, Solaris, etc...) et que les auteurs conseillent les tubes...

M'enfin, faire un truc aussi proche du système et vouloir que ce soit portable, c'est un peu casse-gueule vous trouvez pas ?

'Tain, t'as fait fort tu as sorti du Caml Unix !!

Le 24 novembre 2004 - 18 h 19, gege38 a écrit : http://www.enseignement.polytechnique.fr/profs/informatique/Didier.Remy/system/camlunix/sign.html http://www-gtr.iutv.univ-paris13.fr/Cours/Mat/Systeme/CoursUnixGTR/chap-10_chap-10.html Vous noterez qu'apparemment le traitement des signaux est différent suivant la version Nix (BSD, Solaris, etc...) et que les auteurs conseillent les tubes... M'enfin, faire un truc aussi proche du système et vouloir que ce soit portable, c'est un peu casse-gueule vous trouvez pas ?

ben de toutes façons, tu as raison, si ça doit être portable, les tubes ("pipes" , ce que j'avais préconisé) c'est ce qu'il y a de mieux. Je me demande même pourquoi, dans cette école, ils font faire des trucs aussi spécifiques à un système. Ils savent ce que c'est, la portabilité ? Ou alors ils forment des ingénieurs système très spécialisés ?

mais en fait si woofy ne peut pas utiliser les fonctions de fichiers, c'est mort pour les tubes !

à moins que la série mkfifo/open/write/read/close ne soit autorisée, et là c'est bon...

alors... leçon de pipes pour woofy !

les tubes sont des fichiers spéciaux qui permettent à deux processus de se communiquer des infos, justement...
on utilise des tubes anonymes dans le cas de processus forkés et sinon des tubes nommés, ou FIFO.

le tube s'utilise comme un fichier classique ; le nommé est créé avec mkfifo dans le dossier au choix du programmeur. L'anonyme est en fait un tableau de deux entiers qui seront des descripteurs de fichiers ; on passe le tableau à la fonction pipe() qui le remplit, la case 0 étant pour la lecture et 1 pour l'écriture si je me souviens bien. Ces descripteurs sont partagés par les processus après le fork. il est conseillé dans chaque processus de fermer le bout qui n'est pas utilisé.

on ouvre un tube nommé bêtement avec open(), en écriture par un processus et en lecture par l'autre (le fifo Unix est à sens unique).
open bloque tant que les deux bouts du tube ne sont pas ouverts ; ensuite, il y a juste à écrire d'un côté et lire de l'autre avec read et write

alors voilà, si tu peux utiliser ce genre de choses, c'est parfait.


note : de toute façon, sans open et tout ça, tu ne peux rien faire de vraiment avancé une liste précise ce serait bien en effet

Le 24 novembre 2004 - 17 h 58, gege38 a écrit : Le 24 novembre 2004 - 17 h 27, Woofy a écrit : Bon ben en fait c'etait des problemes de lib. Bon, ca compile sans warning sur les 3 archi, ca marche sur NetBSD, ca marche sur alpha, mais j'ai une segfault aleatoire sur Sun, parfois (genre je le lance 50fois ca passe, la 51eme passe plus, je relance ca plante au bout de la 40eme, ...) Bizzare ?? Je rappelle que les signaux dependent des architectures

signal sous NetBSD et sigset sous alpha et sun.
Pour SIGUSR1 et SIGUSR2, de toute façon je me fout un peu de quelle valeurs ils sont, quel que soit le systeme, tqnt qu'ils sont identifiés en tant que SIGUSR1 et 2 ca me va.

Ce miniproj est fait pour nous faire travailler sur les signaux, donc forcement on en bouffe. Pour la portabilité, j'ai juste fait une macro qui va definir la fonction a utiliser en fonction de l'archi.
Je laisse en l'etat, car ca fonctionne hormis le micro bug qui ne sera pas testé sous sun, et je ne suis pas le seul a avoir ce probleme.
Bon, projet suivant! le COREWAR!!


Ben ca fait plusieurs fois que je lis le sujet, je comprend toujours rien!

Sinon on a un gros projet de PHP/MySQL a faire pour le 24 mai... mais on aura jamais de cours de PHP / MySQL!

Heureusement que je commence a maitriser!

ouah ça devient sérieux !

vous devez faire vous-même les spécifications de la vm ou on vous donne quand même ça ?

heu... je veut bien te poser le lien du sujet... ca doit être possible... 2s...

Le sujet du corewar
op.c
op.h