Si c'est gens avaient eu l'idee de regarder une fois les menus de VC++ ils auraient remarque dans le menu Insert, l'entree New Class qui est en 1ere position dans le menu, et qui oh miracle cree un fichier par classe, s'occupe de mettre ton destructeur en virtual et mettre des #ifndef BLABLA #define BLABLA autour du contenu de ton .hpp
En gros t'utilises ca et tu crees une nouvelle classe tres facilement, ca encourage les neuneus a l'utiliser, et ca cree 1 fichier par classe.
Tu voles la propriete intellectuelle du concepteur en piratant son soft, donc oui il y a vol. Il y a des crimes pires que d'autres, le kidnapping est surement pire que le piratage, ca n'empeche que le piratage est illegal et represente un vol. Dans "propriete intellectuelle" il y a le mot "propriete" au cas ou tu n'aurais pas remarque, si tu t'appropries ce qui m'appartient sans mon accord tu me voles.
Quand a l'interet commun ben c'est justement le cas, l'interet commun c'est de ne pas laisser les gens s'approprier tes biens sans ton consentement, et en piratant tu violes cela.
Tu utilises un soft que j'ai ecrit sans mon consentement, tu me voles, point. Donc oui yeupou, tu es un voleur.
Maintenant il y a 2 types de voleurs:
- ceux qui volent par necessite, ils ont un reel besoin genre se nourrir, avoir un toit,..., qu'ils ne peuvent pas payer. Ils ne volent donc pas par choix mais par necessite, c'est excusable.
- ceux qui volent par facilite et gout du luxe, ils pourraient tout a fait se passer de ce qu'ils volent mais volent quand meme soit parce qu'ils n'ont pas les moyens de se payer ce luxe, soit parce qu'ils ne veulent pas depenser leur argent la dessus, ceux la je ne vois pas pourquoi on leur ferait le moindre cadeau.
Et mon petit doigt me dit que tu n'avais pas un besoin vital de jouer a des jeux pirates et que tu aurais tres bien pu t'en passer, j'en deduis que tu entres dans la 2eme categorie.
Donc si je comprends bien, tu consideres que ces lois sur le piratage sont completement idiotes, inutiles et donc qu'il ne faut pas les respecter ?
J'esperes que personne ne pense comme ca, sinon notre monde est vraiment mal barre.
Tiens moi j'estimes que kidnapper les riches ca ne lese personne, apres tout 1 million de rancon sur le milliard qu'ils ont c'est rien du tout, au total c'est comme si ils avaient rien perdu.
Ah c'est beau les gens qui refont les lois a leurs gouts.
Je n'ai jamais update mon systeme par autre chose que WindowsUpdate, et il n'est pas vulnerable a l'attaque. Tout simplement parce que le fix etait dans un autre patch pour IE.
J'ecris un soft qui recoit et fait des connectiosn reseau que je mets en GPL, je fais bien attention a poser dedans un buffer overflow bien cache. Resultat, je peux faire le con avec n'importe quelle machine qui a ce soft.
Trouver un buffer overflow bien cache en faisant une code review c'est hyper dur, tu prends ca, le nombre de gens qui vont effectivement lire le code du soft(faible), et tu en deduis que je serais tranquille pendant un bon moment, et le jour ou il est decouvert, ben je dis "Ah mais croyez mo, c'est un bug ! C'est un buffer overflow, ca peut arriver a tout le monde !"
Preuve en est que sendmail et wu_ftpd se retrouvent encore avec des alertes pour buffer overflow alors que c'est parmis les softs les plus connus, les plus utilises, les plus anciens, donc les plus audites.
Et le plus drole: vu que je sais exactement quel est le probleme(vu que c'est moi qui l'ai mis), je peux le corriger en 1 heure, et apres je recois les acclamations de la foule qui me considere des lors comme un gars qui prend la securite au serieux.
Alors bon la confiance dans les LL, tu repasseras, que le code soit accessible ou pas, mettre des backdoors est tres simple.
Debian met 35 jours en moyenne pour corriger un trou de securite, Microsoft qui se fait tout le temps critiquer pour etre lent a sortir les patchs, refuser de les sortir, etc... met moins de temps que ca.
Donc si MS est effectivement comme bcp de "fans" de Linux/du libre le disent, lent pour corriger les defauts, ca veut dire que les autres sont bien plus rapides que MS, j'en deduis que Debian, qui est pourtant regarde comme etant tres serieux et tout, est tres lent vu qu'il est plus lent que MS qui est deja lent.
Ou alors c'est peut-etre que MS est tres loin d'etre le plus lent et que Debian est juste un petit peu lent.
Je lis:
" GMutex is not guaranteed to be recursive, i.e. a thread might block, if it already has locked the GMutex. It will deadlock then, of course."
Un thread ne peut pas locker 2 fois de suite le meme mutex. Donc ton P2 ne fonctionne pas, le 1er g_mutex_lock(mutex2) et le dernier se suivent des la 2eme boucle --> deadlock car P2 ne peut pas unlocker mutex2 vu qu'il est bloque sur le deuxieme g_mutex_lock(mutex2).
Si ton process 1 fait son boulot periodique et acquiert le mutex(le lock a la fin dans la fonction my_func) avant que le 2eme process ait ete schedule, le 2eme process ne pourra par faire son boulot car il sera encore bloque sur son g_mutex_lock(mutex).
D'autre part, il y a le probleme suivant(on regarde en boucle):
C'est pas le probleme, Windows n'a jamais essaye d'etre un Unix, c'est un OS completement different.
Porter les softs d'un Unix a l'autre ne pose en general pas de problemes, hors dans ce cas la, le comportement est different entre Linux et les autres Unix sans aucune raison valable, et le pire c'est que ca se voit pas a la compilation, faut le savoir sinon t'es dans la merde. Et il est impossible de rendre son soft portable sans faire des cochonneries.
En gos ca rend le portage des applis multithread tres complexe, sans compter le fait qu'il est impossible de le faire sur les kernels <2.4.
Oui mais si tu utilises clone, ton soft devient Linux only, impossible de porter ca sur xxxBSD, Solaris, IRIX ou autres, c'est pas tres utilisable a moins de commencer a jouer avec des #define.
Comment tu fais pour synchroniser 2 processus separes avec ca ?
Tu as 2 processus:
1 fait un boulot xyz, et pose un timer pour se reveiller dans 20 secondes chaque fois avant de prendre un autre job.
l'autre processus a besoin de se reveiller en meme temps que le processus 1 car il a des trucs a faire avec le boulot du process 1.
Pas possible avec ta methode, il n'y a aucun moyen de signaler au 2eme processus qu'il faut se reveiller, tout simplement car ton timer est local a un thread. Pour faire un truc du genre il faut un truc qui soit accessible globalement sur le systeme comme les mutex et semaphores. Ca serait en theorie possible en rajoutant du bordel pour balancer des signaux a l'autre process, mais la ton soft devient dependant du 2eme process, il doit le connaitre. Avec un timer global, le 1er process n'a meme pas besoin de savoir que le 2eme existe, le 2eme prend un handle sur le meme timer et fait son job.
L'exemple ici present non il sert a rien, je l'ai cree de toute piece, mais ca pourrait tout a fait servir, tout depend de ce que tu fais.
Des threads qui doivent se reveiller a des intervalles precis c'est hyper frequent, pouvoir specifier plus d'un intervalle par thread c'est utile aussi.
Ensuite avoir plusieurs threads qui font de meme avec des timers differents, c'est simplement plusieurs requetes qui ont ete faites, rien d'extraordinaire.
Tu peux tout a fait imaginer plusieures sources de donnees, certaines produisent de nouvelles donnees toutes les 30 secondes, d'autres toutes les 2 minutes 10, etc...
Un thread peut avoir besoin des donnees de la source 1 et la source 4, un autre des sources 2,3 et 5, etc... Voila, ca te donne le probleme ci-dessus.
Mon soft n'avait rien de bas niveau, c'etait 100% user-mode. Et j'ai ete oblige de le refaire justement a cause de ce probleme de PID qui fait que ce n'est pas le process lui meme qui recoit le SIGCHLD et le refile a un thread, mais le thread createur, qui pourrait tout a fait avoir disparu. Et ca c'est : 1) contraire a la norme 2) TRES embetant, la preuve en est que j'ai du completement modifie mon soft a cause de ca, et je suis surement pas le seul dans ce cas, sans compter que le resultat est moins performant que le soft original.
Oui mais tu ne sais pas que c'est instable jusqu'au moment ou il te claque dans les doigts, c'est bien ca le probleme.
T'en sais rien, peut-etre que ces drivers qui sont dans le kernels depuis des annees ont des bugs qui font des kernel panics, mais personne n'a encore eu la malchance de tomber dessus.
Tu n'es jamais sur a 100% qu'un soft est bug free, ca vaut aussi pour les drivers.
L'exemple que j'ai pris(PID differents) a pour consequence que:
- Certaines choses sont rendues bien plus compliquees par rapport a d'autres systemes
- Ca oblige a refaire l'architecture des softs a cause d'un systeme qui fait differemment de tous les autres Unix
En gros ca fait bien chier et quand on sait que PID veut dire PROCESS ID, on se demande comment les threads d'un meme process ont un PID different.
Pour ce qui est du timing, c'est donc bien ce que je disais, il faut faire un truc assez moche(mettre le code pour l'attente hors du thread, pas un bon design car tu delocalise le code) qui prend plus de ressources(1 thread en plus qui gere la chose) et il faut gerer quand tu ajoutes des threads, enleve,... histoire que le thread de gestion se melange pas les pinceaux et oublie pas de threads.
Sinon pour mon probleme a moi, ben OUI laisser sur un waitpid() c'est un TRES GROS probleme.
Apres 500 connections tu te retrouves avec 500 threads attendant sur un waitpid(), dans le genre performance killer c'est dans le top 10, le scheduler il claque avec ca(sans compter les 2Mo de stack bouffes par chaque thread). Quand tu fais du load balancing t'essayes d'habitude d'avoir les meilleures perfs possibles, le waitpid() c'est hors de question.
Ca depend si tu consideres qu'un driver est une partie du kernel ou pas.
Un des drivers fait le con, et degueulasse des structures du kernel mais pas trop, ca crashe pas immediatement.
Le kernel fait son petit bout de chemin, et apres un petit moment se met a traiter ces donnees corrompues, il voit que c'est le merdier --> kernel panic.
Super, et moi aussi j'en ai vu des kernel panic, je pourrais donc faire le meme genre de deduction que toi, mais j'ai l'honnetete de me dire que ca vient peut-etre d'autre chose que de l'OS plutot que critiquer l'OS immediatement.
Mais a part ca, je vois pas trop ce que ca a voir avec le sujet, on parlait de multithreading/multitache et multiprocessing.
- pour des raisons precisees dans la doc(les threads de managment n'ont plus le temps de tourner si un thread de plus haute priorite monopolise le CPU trop longtemps)
- infaisable par quiconque d'autre que l'administrateur
Tout comme ecrire dans /dev/kmem peut faire torcher ta machine.
En gros c'est une facilite donnee aux gens, en leur disant bien que c'est dangereux et comment faire pour ne pas torcher le systeme, et son utilisation est interdite a quiconque d'autre que l'admin pour eviter les abus, maintenant si tu trouves que ce genre de choses est un bug, ben faudra penser a corriger pas mal de choses se trouvant dans /dev et dans /proc.
Windows n'implemente pas mieux les normes POSIX vu que ce n'est pas un systeme qui se veut POSIX, mais il fait les choses correctement et proprement lui, ce qui n'est pas vraiment le cas du multithread sous Linux.
Sinon, tu me montres comment sous Linux tu fais la chose suivante:
4 threads qui tournent.
1 thread se reveille toutes les 30 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 40 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 30 secondes, les 40 secondes et les 2 minutes 15.
1 thread se reveille toutes les 30 secondes et les 40 secondes.
Et inutile de decrire la peine que j'ai eu a trouver cette doc, sur la page de Linuxthreads il est dit que c'est maintenant partie de la libc, et dans la doc de la libc pas un seul mot sur les threads.
Voila, tu peux aller t'amuser a modifier le handler de SIGALRM et faire un code degueu pour ca vu que les signaux sont partages par tous les threads, ou bien creer un thread qui passe son temps a recevoir les signaux et les dispatcher aux autres threads, pendant ce temps moi je cree sous Windows 3 objets timer , je leur assigne les temps, je fais WaitForMultipleObjects() dans chaque thread et c'est fini, c'est moins couteux en ressources car chaque thread n'est reveille que quand c'est necessaire et c'est plus propre a programmer. Mais bon ca c'est pas vraiment la faute a Linux, quasiment tous les Unix sont comme ca.
Si tu veux on peut aussi parler du probleme suivant:
T'as un soft qui cree un thread a chaque connection, le thread fait 2-3 choses et cree un process(avec fork) avec des droits reduits histoire de faire d'autres choses qui peuvent durer longtemps, apres le fork() le thread n'a plus d'utilite donc il est detruit, par contre tu veux savoir quand le process enfant est termine pour nettoyer 2-3 trucs.
Ben avec Linux tu peux t'amuser, le PID parent du process enfant c'est le PID du thread qui a ete detruit, resultat il est impossible de le faire savoir au process grace au signal SIGCHLD et il faut faire des magouilles degueulasses genre stocker les PID des child process et faire du polling pour savoir si ils existent encore.
Et c'est pas un exemple theorique, c'est un soft de load balancing que j'avais ecrit sous Solaris et que j'ai du modifier de maniere assez lourde pour qu'il veuille bien tourner sous Linux, et inutile de dire que c'est bien moins performant comme methode, mais bon il n'y a pas le choix vu le bug.
Notes que sous Windows on n'a pas encore de patchs pour pouvoir interrompre les threads quand elles sont dans le kernel, c'est d'origine :+)
Ah aussi, les affinites de threads avec les processeurs aussi, les I/O completion ports, les threads du meme process qui ont la bonne idee d'avoir toutes le meme process ID contrairement a certaines implementations que je ne citerais pas, les threads signalables sur des timers, sur des threads,...
A real-time operating system (RTOS) is an operating system that guarantees a certain capability within a specified time constraint
Maintenant sachant que AmigaOS ne te garantit rien de ce genre, tu m'expliqueras en quoi il est temps reel. Si tu me montres ou dans les docs il est dit le contraire, je serais ravi de dire que je me suis trompe.
Quand a TripOS, faudrait peut-etre comprendre que tu peux etre "XXX-like" sans etre ecrit dans le meme langage que le "XXX". Le fait que les pointeurs BCPL aient disparu ne change rien au fait que l'OS est un derive de TripOS, pas de Unix, l'OS n'a pas change d'architecture quand ils ont vire BCPL, ils ont juste repondu le code dans un autre langage.
AmigaOS c'est TripOS avec Exec et des couches dessus genre Intuition et autres, le code BCPL a ensuite ete remplace par du C, ca ne change rien au fait qu'il est derive de TripOS, pas de Unix.
cf http://www.thule.no/haynie/caos.html(...(...)) pour une explication par Andy Finkel himself sur l'histoire de la creation d'AmigaOS, et il dit bien clairement: "based on an already existing OS known as Tripos". Maintenant si tu n'es pas d'accord avec Finkel, ca devient plutot drole.
Quand a mes convictions delirantes, ben bof... j'en ai surement mais je vis bien avec, donc je ne comptes aller chez un psy apres reflexion.
C'est le 1er ordinateur que j'ai eu, et il a tenu de 1988 jusqu'a mon depart a Seattle. J'avais bien essaye de trouver quelqu'un a qui le donner mais personne ne se manifestait et la mort dans l'ame j'ai du l'amener a la decharge. J'aurais jamais cru qu'un ordinateur pourrait me tirer une larme, mais pourtant si, j'avais l'impression de trahir un ami quand je l'ai pose dans le box.
[^] # Re: interet d'une IDE sous Linux
Posté par pasBill pasGates . En réponse à la dépêche C++ Builder sous Linux : bientôt du neuf !. Évalué à 4.
En gros t'utilises ca et tu crees une nouvelle classe tres facilement, ca encourage les neuneus a l'utiliser, et ca cree 1 fichier par classe.
[^] # Re: mauvais calcul -> espece de pirate!
Posté par pasBill pasGates . En réponse à la dépêche Loki met bientôt la clef sous la porte. Évalué à 1.
Quand a l'interet commun ben c'est justement le cas, l'interet commun c'est de ne pas laisser les gens s'approprier tes biens sans ton consentement, et en piratant tu violes cela.
Tu utilises un soft que j'ai ecrit sans mon consentement, tu me voles, point. Donc oui yeupou, tu es un voleur.
Maintenant il y a 2 types de voleurs:
- ceux qui volent par necessite, ils ont un reel besoin genre se nourrir, avoir un toit,..., qu'ils ne peuvent pas payer. Ils ne volent donc pas par choix mais par necessite, c'est excusable.
- ceux qui volent par facilite et gout du luxe, ils pourraient tout a fait se passer de ce qu'ils volent mais volent quand meme soit parce qu'ils n'ont pas les moyens de se payer ce luxe, soit parce qu'ils ne veulent pas depenser leur argent la dessus, ceux la je ne vois pas pourquoi on leur ferait le moindre cadeau.
Et mon petit doigt me dit que tu n'avais pas un besoin vital de jouer a des jeux pirates et que tu aurais tres bien pu t'en passer, j'en deduis que tu entres dans la 2eme categorie.
[^] # Re: mauvais calcul -> espece de pirate!
Posté par pasBill pasGates . En réponse à la dépêche Loki met bientôt la clef sous la porte. Évalué à -4.
J'esperes que personne ne pense comme ca, sinon notre monde est vraiment mal barre.
Tiens moi j'estimes que kidnapper les riches ca ne lese personne, apres tout 1 million de rancon sur le milliard qu'ils ont c'est rien du tout, au total c'est comme si ils avaient rien perdu.
Ah c'est beau les gens qui refont les lois a leurs gouts.
[^] # Re: Quelle va être la réponse de Microsoft ?
Posté par pasBill pasGates . En réponse à la dépêche Le plus gros trou de sécurité de IE. Évalué à 0.
Je n'ai jamais update mon systeme par autre chose que WindowsUpdate, et il n'est pas vulnerable a l'attaque. Tout simplement parce que le fix etait dans un autre patch pour IE.
[^] # Re: exemple même de ce que je dis !
Posté par pasBill pasGates . En réponse à la dépêche Le plus gros trou de sécurité de IE. Évalué à 1.
[^] # Re: Logiciel Libre != sécurité mais LL = confiance.
Posté par pasBill pasGates . En réponse à la dépêche Le plus gros trou de sécurité de IE. Évalué à 2.
J'ecris un soft qui recoit et fait des connectiosn reseau que je mets en GPL, je fais bien attention a poser dedans un buffer overflow bien cache. Resultat, je peux faire le con avec n'importe quelle machine qui a ce soft.
Trouver un buffer overflow bien cache en faisant une code review c'est hyper dur, tu prends ca, le nombre de gens qui vont effectivement lire le code du soft(faible), et tu en deduis que je serais tranquille pendant un bon moment, et le jour ou il est decouvert, ben je dis "Ah mais croyez mo, c'est un bug ! C'est un buffer overflow, ca peut arriver a tout le monde !"
Preuve en est que sendmail et wu_ftpd se retrouvent encore avec des alertes pour buffer overflow alors que c'est parmis les softs les plus connus, les plus utilises, les plus anciens, donc les plus audites.
Et le plus drole: vu que je sais exactement quel est le probleme(vu que c'est moi qui l'ai mis), je peux le corriger en 1 heure, et apres je recois les acclamations de la foule qui me considere des lors comme un gars qui prend la securite au serieux.
Alors bon la confiance dans les LL, tu repasseras, que le code soit accessible ou pas, mettre des backdoors est tres simple.
[^] # Re: exemple même de ce que je dis !
Posté par pasBill pasGates . En réponse à la dépêche Le plus gros trou de sécurité de IE. Évalué à -2.
Donc si MS est effectivement comme bcp de "fans" de Linux/du libre le disent, lent pour corriger les defauts, ca veut dire que les autres sont bien plus rapides que MS, j'en deduis que Debian, qui est pourtant regarde comme etant tres serieux et tout, est tres lent vu qu'il est plus lent que MS qui est deja lent.
Ou alors c'est peut-etre que MS est tres loin d'etre le plus lent et que Debian est juste un petit peu lent.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 1.
Je lis:
" GMutex is not guaranteed to be recursive, i.e. a thread might block, if it already has locked the GMutex. It will deadlock then, of course."
Un thread ne peut pas locker 2 fois de suite le meme mutex. Donc ton P2 ne fonctionne pas, le 1er g_mutex_lock(mutex2) et le dernier se suivent des la 2eme boucle --> deadlock car P2 ne peut pas unlocker mutex2 vu qu'il est bloque sur le deuxieme g_mutex_lock(mutex2).
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 1.
Sinon, ce genre de choses est plus frequent que tu ne pourrais le penser.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 1.
Si ton process 1 fait son boulot periodique et acquiert le mutex(le lock a la fin dans la fonction my_func) avant que le 2eme process ait ete schedule, le 2eme process ne pourra par faire son boulot car il sera encore bloque sur son g_mutex_lock(mutex).
D'autre part, il y a le probleme suivant(on regarde en boucle):
P1...................P2
lock(mutex)
attend
unlock(mutex)
bosse...............lock(mutex)
......................bosse
......................unlock(mutex)
lock(mutex)
lock(mutex)
attend
unlock(mutex)........--> P2 ne peut pas locker le mutex, car P1 a fait 2 locks de suite, il faut donc 2 unlock
bosse
lock(mutex)
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à -1.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 0.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 1.
Comment tu fais pour synchroniser 2 processus separes avec ca ?
Tu as 2 processus:
1 fait un boulot xyz, et pose un timer pour se reveiller dans 20 secondes chaque fois avant de prendre un autre job.
l'autre processus a besoin de se reveiller en meme temps que le processus 1 car il a des trucs a faire avec le boulot du process 1.
Pas possible avec ta methode, il n'y a aucun moyen de signaler au 2eme processus qu'il faut se reveiller, tout simplement car ton timer est local a un thread. Pour faire un truc du genre il faut un truc qui soit accessible globalement sur le systeme comme les mutex et semaphores. Ca serait en theorie possible en rajoutant du bordel pour balancer des signaux a l'autre process, mais la ton soft devient dependant du 2eme process, il doit le connaitre. Avec un timer global, le 1er process n'a meme pas besoin de savoir que le 2eme existe, le 2eme prend un handle sur le meme timer et fait son job.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 1.
Des threads qui doivent se reveiller a des intervalles precis c'est hyper frequent, pouvoir specifier plus d'un intervalle par thread c'est utile aussi.
Ensuite avoir plusieurs threads qui font de meme avec des timers differents, c'est simplement plusieurs requetes qui ont ete faites, rien d'extraordinaire.
Tu peux tout a fait imaginer plusieures sources de donnees, certaines produisent de nouvelles donnees toutes les 30 secondes, d'autres toutes les 2 minutes 10, etc...
Un thread peut avoir besoin des donnees de la source 1 et la source 4, un autre des sources 2,3 et 5, etc... Voila, ca te donne le probleme ci-dessus.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à -1.
Mon soft n'avait rien de bas niveau, c'etait 100% user-mode. Et j'ai ete oblige de le refaire justement a cause de ce probleme de PID qui fait que ce n'est pas le process lui meme qui recoit le SIGCHLD et le refile a un thread, mais le thread createur, qui pourrait tout a fait avoir disparu. Et ca c'est : 1) contraire a la norme 2) TRES embetant, la preuve en est que j'ai du completement modifie mon soft a cause de ca, et je suis surement pas le seul dans ce cas, sans compter que le resultat est moins performant que le soft original.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à -3.
T'en sais rien, peut-etre que ces drivers qui sont dans le kernels depuis des annees ont des bugs qui font des kernel panics, mais personne n'a encore eu la malchance de tomber dessus.
Tu n'es jamais sur a 100% qu'un soft est bug free, ca vaut aussi pour les drivers.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 0.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à -3.
- Certaines choses sont rendues bien plus compliquees par rapport a d'autres systemes
- Ca oblige a refaire l'architecture des softs a cause d'un systeme qui fait differemment de tous les autres Unix
En gros ca fait bien chier et quand on sait que PID veut dire PROCESS ID, on se demande comment les threads d'un meme process ont un PID different.
Quand a la doc de glibc, ben sur http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_toc.html(...) il n'y a rien du tout, tu l'a prise ou ou ta doc ?
Pour ce qui est du timing, c'est donc bien ce que je disais, il faut faire un truc assez moche(mettre le code pour l'attente hors du thread, pas un bon design car tu delocalise le code) qui prend plus de ressources(1 thread en plus qui gere la chose) et il faut gerer quand tu ajoutes des threads, enleve,... histoire que le thread de gestion se melange pas les pinceaux et oublie pas de threads.
Sinon pour mon probleme a moi, ben OUI laisser sur un waitpid() c'est un TRES GROS probleme.
Apres 500 connections tu te retrouves avec 500 threads attendant sur un waitpid(), dans le genre performance killer c'est dans le top 10, le scheduler il claque avec ca(sans compter les 2Mo de stack bouffes par chaque thread). Quand tu fais du load balancing t'essayes d'habitude d'avoir les meilleures perfs possibles, le waitpid() c'est hors de question.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 0.
Un des drivers fait le con, et degueulasse des structures du kernel mais pas trop, ca crashe pas immediatement.
Le kernel fait son petit bout de chemin, et apres un petit moment se met a traiter ces donnees corrompues, il voit que c'est le merdier --> kernel panic.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à -4.
Mais a part ca, je vois pas trop ce que ca a voir avec le sujet, on parlait de multithreading/multitache et multiprocessing.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 0.
Quand a m'accabler... ben prouve moi que c'est plus dangereux que /dev/kmem et on en reparlera.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 3.
- uniquement pour les priorites REALTIME
- pour des raisons precisees dans la doc(les threads de managment n'ont plus le temps de tourner si un thread de plus haute priorite monopolise le CPU trop longtemps)
- infaisable par quiconque d'autre que l'administrateur
Tout comme ecrire dans /dev/kmem peut faire torcher ta machine.
En gros c'est une facilite donnee aux gens, en leur disant bien que c'est dangereux et comment faire pour ne pas torcher le systeme, et son utilisation est interdite a quiconque d'autre que l'admin pour eviter les abus, maintenant si tu trouves que ce genre de choses est un bug, ben faudra penser a corriger pas mal de choses se trouvant dans /dev et dans /proc.
Windows n'implemente pas mieux les normes POSIX vu que ce n'est pas un systeme qui se veut POSIX, mais il fait les choses correctement et proprement lui, ce qui n'est pas vraiment le cas du multithread sous Linux.
Sinon, tu me montres comment sous Linux tu fais la chose suivante:
4 threads qui tournent.
1 thread se reveille toutes les 30 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 40 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 30 secondes, les 40 secondes et les 2 minutes 15.
1 thread se reveille toutes les 30 secondes et les 40 secondes.
J'ai beau avoir gratte la doc sur http://www.unix-systems.org/single_unix_specification_v2/xsh/thread(...)) et dans mon superbe bouquin de Richard Stevens j'ai rien vu d'evident pour faire ca, peut-etre en jouant avec des conditions et encore j'en suis pas sur du tout.
Et inutile de decrire la peine que j'ai eu a trouver cette doc, sur la page de Linuxthreads il est dit que c'est maintenant partie de la libc, et dans la doc de la libc pas un seul mot sur les threads.
Voila, tu peux aller t'amuser a modifier le handler de SIGALRM et faire un code degueu pour ca vu que les signaux sont partages par tous les threads, ou bien creer un thread qui passe son temps a recevoir les signaux et les dispatcher aux autres threads, pendant ce temps moi je cree sous Windows 3 objets timer , je leur assigne les temps, je fais WaitForMultipleObjects() dans chaque thread et c'est fini, c'est moins couteux en ressources car chaque thread n'est reveille que quand c'est necessaire et c'est plus propre a programmer. Mais bon ca c'est pas vraiment la faute a Linux, quasiment tous les Unix sont comme ca.
Si tu veux on peut aussi parler du probleme suivant:
T'as un soft qui cree un thread a chaque connection, le thread fait 2-3 choses et cree un process(avec fork) avec des droits reduits histoire de faire d'autres choses qui peuvent durer longtemps, apres le fork() le thread n'a plus d'utilite donc il est detruit, par contre tu veux savoir quand le process enfant est termine pour nettoyer 2-3 trucs.
Ben avec Linux tu peux t'amuser, le PID parent du process enfant c'est le PID du thread qui a ete detruit, resultat il est impossible de le faire savoir au process grace au signal SIGCHLD et il faut faire des magouilles degueulasses genre stocker les PID des child process et faire du polling pour savoir si ils existent encore.
Et c'est pas un exemple theorique, c'est un soft de load balancing que j'avais ecrit sous Solaris et que j'ai du modifier de maniere assez lourde pour qu'il veuille bien tourner sous Linux, et inutile de dire que c'est bien moins performant comme methode, mais bon il n'y a pas le choix vu le bug.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à -3.
Notes que sous Windows on n'a pas encore de patchs pour pouvoir interrompre les threads quand elles sont dans le kernel, c'est d'origine :+)
Ah aussi, les affinites de threads avec les processeurs aussi, les I/O completion ports, les threads du meme process qui ont la bonne idee d'avoir toutes le meme process ID contrairement a certaines implementations que je ne citerais pas, les threads signalables sur des timers, sur des threads,...
Non, faut rester serieux quand meme.
[^] # Re: Retour vers le futur, un témoignage :
Posté par pasBill pasGates . En réponse à la dépêche une Debian sur noyau NetBSD. Évalué à 3.
A real-time operating system (RTOS) is an operating system that guarantees a certain capability within a specified time constraint
Maintenant sachant que AmigaOS ne te garantit rien de ce genre, tu m'expliqueras en quoi il est temps reel. Si tu me montres ou dans les docs il est dit le contraire, je serais ravi de dire que je me suis trompe.
Quand a TripOS, faudrait peut-etre comprendre que tu peux etre "XXX-like" sans etre ecrit dans le meme langage que le "XXX". Le fait que les pointeurs BCPL aient disparu ne change rien au fait que l'OS est un derive de TripOS, pas de Unix, l'OS n'a pas change d'architecture quand ils ont vire BCPL, ils ont juste repondu le code dans un autre langage.
AmigaOS c'est TripOS avec Exec et des couches dessus genre Intuition et autres, le code BCPL a ensuite ete remplace par du C, ca ne change rien au fait qu'il est derive de TripOS, pas de Unix.
cf http://www.thule.no/haynie/caos.html(...(...)) pour une explication par Andy Finkel himself sur l'histoire de la creation d'AmigaOS, et il dit bien clairement: "based on an already existing OS known as Tripos". Maintenant si tu n'es pas d'accord avec Finkel, ca devient plutot drole.
Quand a mes convictions delirantes, ben bof... j'en ai surement mais je vis bien avec, donc je ne comptes aller chez un psy apres reflexion.
[^] # Re: Retour vers le futur, un témoignage :
Posté par pasBill pasGates . En réponse à la dépêche une Debian sur noyau NetBSD. Évalué à 1.
C'est le 1er ordinateur que j'ai eu, et il a tenu de 1988 jusqu'a mon depart a Seattle. J'avais bien essaye de trouver quelqu'un a qui le donner mais personne ne se manifestait et la mort dans l'ame j'ai du l'amener a la decharge. J'aurais jamais cru qu'un ordinateur pourrait me tirer une larme, mais pourtant si, j'avais l'impression de trahir un ami quand je l'ai pose dans le box.