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.
C'est surtout qu'Apple ne VEUT pas le distribuer sur PC.
Apple c'est une image 'artiste', 'differente', les Macs ont un design bien demarque du reste, et c'est le hardware qui rapporte de l'argent a Apple. Si Apple sort MacOS X sur PC, ils perdent cette image ce qui est mauvais pour eux, et les gens vont se mettre a acheter un PC Dell plutot qu'un Mac, ce qui va faire perdre des dollars a Apple.
C'est d'ailleurs pour cela que Jobs a casse tous les contrats de licence avec les cloneurs Mac quand il est arrive, ils prenaient des parts de marche a Apple, et Apple ne gagnait pas grand chose avec les licences.
Faut pas te sentir agresse tu sais, j'ai un Amiga4000 a cote de moi, et je suis pas pres de le lacher.
Simplement dire que ton Amiga a un DSP, ben c'est vrai uniquement avec une carte d'extension, tout comme bon nombre de PC qui ont des cartes sons.
Quand a Tripos, c'est sur qu'il y a problabement plus grand chose qui reste, mais tu parlais d'OS Unix-like, je te disais juste qu'il n'a absolument rien d'Unix-like, il est Tripos-like.
Sinon crois-moi, il n'a absolument rien de temps reel cet OS, aucune garantie sur les temps de reponse. Le noyau de WinNT est lui aussi totalement interruptible, ca n'en fait pas un OS temps reel.
Aucun Amiga n'a de DSP en standard, si t'ajoutes une carte son oui mais sinon pas de DSP.
L'OS n'a rien d'Unix, il est base sur TRIPOS et il n'est pas temps reel, il est considere comme "presque temps reel" mais ne l'est pas, t'as aucune garantie.
Ou ai-je dis qu'utiliser GCC ou un autre compilo GPL rendait ton soft GPL ? Nulle part.
Tu serais sympa de comprendre ce que je dis avant de parler d'intox.
Tu prends du code GPL, tu le mets dans du code proprio, le code proprio devient GPL. Le mot "cancer"(un peu abrupt j'en conviens) vient de la. Le fait de ne pas lire du code GPL chez MS vient de la aussi. Ca veut absolument pas dire qu'il est deconseille d'utiliser gcc et autres sous peine d'avoir son code en GPL.
Vu que tu arrives pas a faire la difference, je vais t'expliquer clairement:
- Il n'y a pas que des linuxiens sur Slashdot
- Etre anti-MS ne signifie pas etre linuxien
- Etre linuxien ne signifie pas etre anti-MS
Une fois que tu auras reussi a comprendre le sens de ces 3 phrases, tu comprendras que "pour faire plus anti-MS, il te faudrait quoi, a part tuer Gates ?", ca ne parle pas plus de linuxiens que d'autres personnes.
Si t'arrives toujours pas a comprendre ca, ben faut retourner a l'ecole, ca veut dire que t'as rate un truc important.
La prochaine fois avant de partir dans ton trip et balancer une diatribe sur moi, MS et ceux qui n'ont pas le meme point de vue que toi, informe toi.
MS a critique ce film et bien fait comprendre qu'il ne l'appreciait pas.
Ton fantasme comme quoi MS ou des pro-MS auraient fait ce film en dit long sur ton mode de pensee.
Donc, si tu pouvais eviter de balancer des conneries, notamment sur mon compte vu que je n'ai jamais dit ou fait comprendre "les linuxiens revent de tuer BillGates" contrairement a ce que tu affirmes, ca serait TRES BIEN.
Dire que je suis de mauvaise foi, d'habitude ca m'amuse, mettre des mots que je n'ai jamais prononce sur mon compte et accuser les gens de XYZ sans AUCUNE preuve, ca par contre je trouve que c'est d'une stupidite effarante et d'un certain manque d'honnetete.
Allez, retournes dans ton bunker faire du lancer de CD Windows.
Si tu veux installer un soft qui se met au demarrage de la machine, si il faut aller trifouiller ces scripts.
Si tu veux faire un soft qui analyse tes logs, faut les trouver.
...
L'avantage de Windows, c'est qu'il a une interface pour acceder a la plupart de ces choses, plutot qu'aller taper direct dans les fichiers, resultat MS pourrait mettre ses fichiers n'importe comment, n'importe ou, c'est transparent aux applications si elles font les choses correctement.
Et sinon, va essayer de modifier les fichiers systemes sous Windows2000 si t'es pas admin, t'iras pas loin.
Une des choses qui manque a Linux, c'est quelque chose qui interface avec ces fichiers, repertoires, etc... histoire que les gens puissent ecrire leurs softs sans s'inquieter de ce qu'il y a dessous, sans ca Linux restera "plusieurs distributions" plutot que "un systeme".
Il n'y a pas 2 PC sous windows installés de la même manière
Ce que tu n'as pas compris:
- Sous Linux, les scripts d'init ne sont pas au meme endroit, pour les trouver faut savoir sur quelle distrib tu tournes
- Sous Windows, le repertoire ou se trouvent les DLL systeme est stocke dans UNE SEULE ET MEME entree dans la registry, meme chose pour a peu pres tout, resultat ton script d'install il utilise ces infos de la registry, et il reste le meme pour n'importe quel Windows. Les versions des DLL, c'est pas ton installer qui s'en occupe, c'est un API du systeme, si tu fais le porc et t'y vas a la main, c'est ton probleme.
[^] # 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.
[^] # Re: MacOS X
Posté par pasBill pasGates . En réponse à la dépêche [Rumeur] AOL racheterait Red Hat ?. Évalué à 6.
Apple c'est une image 'artiste', 'differente', les Macs ont un design bien demarque du reste, et c'est le hardware qui rapporte de l'argent a Apple. Si Apple sort MacOS X sur PC, ils perdent cette image ce qui est mauvais pour eux, et les gens vont se mettre a acheter un PC Dell plutot qu'un Mac, ce qui va faire perdre des dollars a Apple.
C'est d'ailleurs pour cela que Jobs a casse tous les contrats de licence avec les cloneurs Mac quand il est arrive, ils prenaient des parts de marche a Apple, et Apple ne gagnait pas grand chose avec les licences.
[^] # 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.
Simplement dire que ton Amiga a un DSP, ben c'est vrai uniquement avec une carte d'extension, tout comme bon nombre de PC qui ont des cartes sons.
Quand a Tripos, c'est sur qu'il y a problabement plus grand chose qui reste, mais tu parlais d'OS Unix-like, je te disais juste qu'il n'a absolument rien d'Unix-like, il est Tripos-like.
Sinon crois-moi, il n'a absolument rien de temps reel cet OS, aucune garantie sur les temps de reponse. Le noyau de WinNT est lui aussi totalement interruptible, ca n'en fait pas un OS temps reel.
[^] # 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.
L'OS n'a rien d'Unix, il est base sur TRIPOS et il n'est pas temps reel, il est considere comme "presque temps reel" mais ne l'est pas, t'as aucune garantie.
[^] # Re: Soyons réalistes
Posté par pasBill pasGates . En réponse à la dépêche Le monde libre sur Apple. Évalué à 1.
Ou ai-je dis qu'utiliser GCC ou un autre compilo GPL rendait ton soft GPL ? Nulle part.
Tu serais sympa de comprendre ce que je dis avant de parler d'intox.
Tu prends du code GPL, tu le mets dans du code proprio, le code proprio devient GPL. Le mot "cancer"(un peu abrupt j'en conviens) vient de la. Le fait de ne pas lire du code GPL chez MS vient de la aussi. Ca veut absolument pas dire qu'il est deconseille d'utiliser gcc et autres sous peine d'avoir son code en GPL.
[^] # Re: C'est lamentable
Posté par pasBill pasGates . En réponse à la dépêche Qui a tué Bill Gates ?. Évalué à -1.
- Il n'y a pas que des linuxiens sur Slashdot
- Etre anti-MS ne signifie pas etre linuxien
- Etre linuxien ne signifie pas etre anti-MS
Une fois que tu auras reussi a comprendre le sens de ces 3 phrases, tu comprendras que "pour faire plus anti-MS, il te faudrait quoi, a part tuer Gates ?", ca ne parle pas plus de linuxiens que d'autres personnes.
Si t'arrives toujours pas a comprendre ca, ben faut retourner a l'ecole, ca veut dire que t'as rate un truc important.
[^] # Re: C'est lamentable
Posté par pasBill pasGates . En réponse à la dépêche Qui a tué Bill Gates ?. Évalué à 2.
MS a critique ce film et bien fait comprendre qu'il ne l'appreciait pas.
Ton fantasme comme quoi MS ou des pro-MS auraient fait ce film en dit long sur ton mode de pensee.
Donc, si tu pouvais eviter de balancer des conneries, notamment sur mon compte vu que je n'ai jamais dit ou fait comprendre "les linuxiens revent de tuer BillGates" contrairement a ce que tu affirmes, ca serait TRES BIEN.
Dire que je suis de mauvaise foi, d'habitude ca m'amuse, mettre des mots que je n'ai jamais prononce sur mon compte et accuser les gens de XYZ sans AUCUNE preuve, ca par contre je trouve que c'est d'une stupidite effarante et d'un certain manque d'honnetete.
Allez, retournes dans ton bunker faire du lancer de CD Windows.
[^] # Re: LinuxFr : royaume de la mauvaise foi, PBPG y a donc sa place et moi aussi
Posté par pasBill pasGates . En réponse à la dépêche Borland s'installe chez vous (sic) !. Évalué à 1.
Si tu veux faire un soft qui analyse tes logs, faut les trouver.
...
L'avantage de Windows, c'est qu'il a une interface pour acceder a la plupart de ces choses, plutot qu'aller taper direct dans les fichiers, resultat MS pourrait mettre ses fichiers n'importe comment, n'importe ou, c'est transparent aux applications si elles font les choses correctement.
Et sinon, va essayer de modifier les fichiers systemes sous Windows2000 si t'es pas admin, t'iras pas loin.
Une des choses qui manque a Linux, c'est quelque chose qui interface avec ces fichiers, repertoires, etc... histoire que les gens puissent ecrire leurs softs sans s'inquieter de ce qu'il y a dessous, sans ca Linux restera "plusieurs distributions" plutot que "un systeme".
[^] # Re: LinuxFr : royaume de la mauvaise foi, PBPG y a donc sa place et moi aussi
Posté par pasBill pasGates . En réponse à la dépêche Borland s'installe chez vous (sic) !. Évalué à 1.
Ce que tu n'as pas compris:
- Sous Linux, les scripts d'init ne sont pas au meme endroit, pour les trouver faut savoir sur quelle distrib tu tournes
- Sous Windows, le repertoire ou se trouvent les DLL systeme est stocke dans UNE SEULE ET MEME entree dans la registry, meme chose pour a peu pres tout, resultat ton script d'install il utilise ces infos de la registry, et il reste le meme pour n'importe quel Windows. Les versions des DLL, c'est pas ton installer qui s'en occupe, c'est un API du systeme, si tu fais le porc et t'y vas a la main, c'est ton probleme.