Kurshev a pondu un patch de 5KB rendant MPlayer multi-thread comme beaucoup d'autres lecteurs multimédia;Ce patch a été refusé par Aki qui souhaite garder le choix d'un lecteur non threadé.
En visitant le site de MPlayer, on apprend aussi qu'une nouvelle version arrive bientôt.
Aller plus loin
- mplayerXP (4 clics)
- L'annonce sur le site de MPlayer (3 clics)
- L'annonce de Kurshev (2 clics)
# Note du posteur
Posté par Huzi . Évalué à 10.
Perso, je ne suis même pas arrivé à le compiler hier soir ...
merci de votre indulgence !
[^] # Re: Note du posteur
Posté par anonyme512 . Évalué à 10.
et en lisant les liens, je crois que ce n'est pas la seule chose qui motive ce fork en plus. il semble que le type veuille également permettre de changer les librairies liées à mplayer sans avoir forcément besoin de le recompiler, c'est à dire par l'ajout d'une couche d'abstraction, ce qui devrait également avoir pour conséquence de permettre à terme une distribution _binaire_ de MPlayer, ce qui est une très très bonne chose, surtout si l'on considère que le programme doit également pouvoir être utilisé par le plus grand nombre.
[^] # Re: Note du posteur
Posté par VACHOR (site web personnel) . Évalué à 10.
Mais la programmation efficace en multithread est délicate. C'est donc aussi la porte ouverte à de nombreux bugs et comportements non déterministes...
La version multithread doit roulaize à terme.
[^] # Re: Note du posteur
Posté par boubou (site web personnel) . Évalué à 10.
[^] # Que vallent les treads sous UNIX?
Posté par Olivier Brisson . Évalué à 10.
Je cite:
Proxy is an IP filtering proxy server for Linux written by InnerTek Software. It was written to solve the problem of being able to connect to machines behind a Linux firewall. There are both threaded and non-threaded versions of proxy in the download area. Threads were abandoned in release 2.2.3 while we spent some time figuring out the thread limitations in the Linux threads library.
Qui peut apporter des explications? Merci d'avance pour toute explication.
[^] # Re: Que vallent les treads sous UNIX?
Posté par boubou (site web personnel) . Évalué à 10.
La seule idée qui me vient concerne le modèle d'implantation des threads linux : c'est un modèle one-to-one, c'est à dire qu'un thread applicatif correspond à un thread noyau. Ca veut dire qu'avoir 1000 threads dans une application sous linux, ça risque de ramer à mort. Mais il faut être crétin pour avoir 1000 threads dans une application. Ceci étant, certaines implantations des threads sont basées sur des modèles très compliqués many-to-many (cf http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html(...)) qui correspondent en gros à avoir un double ordonnancement, à la fois au niveau utilisateur et au niveau noyau : en gros, un groupe de thread de l'application est représenté par un thread noyau. Ca permet de faire des applications de bourrin, genre 1000 threads, justement.
Le problème, c'est que beaucoup de développeurs pensent que threads => performances, et on arrive à des trucs débiles (toujours les 1000 threads).
[^] # Re: Que vallent les treads sous UNIX?
Posté par Olivier Brisson . Évalué à 0.
[^] # Re: Note du posteur
Posté par Maz (site web personnel) . Évalué à 5.
Ensuite, j'aimerais savoir ce que cela change dans le cas où un autre programme vient afficher une fenêtre (l'exemple de Licq). Personnellement, je ne vois pas de différence entre mono thread et multi thread dans ce cas. Quelqu'un pourrait confirmer/infirmer, avec des explications ?
[^] # threads vs select()
Posté par Cru Kilu . Évalué à 7.
De ce point de vue il n'y a aucune raison de croire qu'un prog multi-threadé serait plus performant qu'un prog non multi-threadé autour d'un select.
Le seul intéret du multithread est lors de calculs intensifs : on peut loger ces calculs dans un thread, tandis qu'un autre gère le GUI par exemple, qui n'est donc pas bloqué pendant le calcul.
On peut toutefois bricoler en logeant des tours de boucle d'évènement au milieu du calcul (gtk permet de faire ça) mais c'est lourd et chiant à gérer.
Je suis d'accord que l'écriture d'un prog avec des threads est délicate because tous les mutex à placer aux bons endroits. Là aussi on peut regarder le code de la glib dans gtk, chauffe Marcel.
[^] # Le fork: enfin libre?
Posté par a_jr . Évalué à 10.
Ici, le fork aura peut-etre l'avantage d'etre libre pour de vrai? Enfin presque: tant que les divx necessitent les codecs non libres de windows, les lecteurs multimedias compatibles divx ne seront pas a la fois 100% libres et 100% fonctionnels.
Le bonjour chez vous,
Yves
[^] # Re: Le fork: enfin libre?
Posté par anonyme512 . Évalué à 10.
après on aura résolu le problème de ce côté là...
reste le gros problème des DVD avec DeCSS, qui est libre, mais illégal aux US (salauds !)
[^] # Re: Le fork: enfin libre?
Posté par xof . Évalué à 1.
Mplayer n'utilise pas DeCSS par défault.
Sur le site de Mplayers, ils recommandent la libdvdcss du videolan project qui est libre et utilise la licence GPL.
cette librairie doit être installée avec la libdvdread, également sous license GPL.
Rassurez moi, là j'ai un doute affreux... elles ne sont pas illégales ces librairies aux USA ?
[^] # Re: Le fork: enfin libre?
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
de toute facons aux US toutes les implementations de decryteurs css sont interdites
[^] # Re: Le fork: enfin libre?
Posté par Gaël Le Mignot . Évalué à 10.
Elle ne passe malheureusement pas parfaitement sur 100% des vidéos, mais par contre les performances sont bien supérieurs à celles des codecs officielles, d'apès mes tests personnels en tout cas.
[^] # Re: Le fork: enfin libre?
Posté par zeb . Évalué à 10.
La raison exacte est que le source contient des fichiers ayant des licences incompatibles. Sous forme de sources, elles sont legalement assemblees, mais pas la redistribution de la version binaire ne l'est pas. Ils sont en train de changer le code non-GPL en code GPL a terme.
De plus ils recommandent la compilation "a la main", car MPlayer est tres dependant des optimisations CPU, et que les routines de detection sont faciles avec un ./configure mais greveraient les performances si l'executable binaire avait cette charge.
[^] # Re: Le fork: enfin libre?
Posté par a_jr . Évalué à 10.
Alors c'est pas un logiciel libre. C'est pas une critique ni un troll, c'est un constat.
ils recommandent la compilation "a la main", car MPlayer est tres dependant des optimisations CPU
Ca, c'est si tu veux un lecteur plus performant.
Mais si le lecteur ne tournait pas sans ces optimisations, alors il serait bon pour la poubelle puisque d'autres (xine, ogle...) le font.
Ensuite, c'est le role des distributions de
- faire des packages en fonction des utilisateurs cibles (redhat x86 vise tous les x86 alors que mandrake x86 ne vise que les 586 et superieurs par exemple)
- faire des packages des logiciels. A toi de recompiler le soft avec tes optimisations si tu le veux et si t'en es capable. L'utilisateur lambda, s'il n'en est pas capable, il sera content d'avoir son package: il n'aurait pas utilise le soft sinon.
Apres, si les distributions veulent faire les choses bien, ils font N packages du meme soft, un par type de machine.
En bref, recommander la compilation "a la main", oui, c'est bien. Utiliser cela comme une raison (j'ai pas dit LA raison) pour interdire la distribution de binaires, NON.
Le bonjour chez vous,
Yves
[^] # Re: Le fork: enfin libre?
Posté par #3588 . Évalué à 3.
>Alors c'est pas un logiciel libre. C'est pas une critique ni un troll, c'est un constat.
Si la seule chose exigée est que la distribution soit faite sous forme de sources et pas de binaires, il y a des chances que çà rentre encore dans la définition de logiciel libre, aussi bien FSF qu'OpenSource.
Évidemment, c'est pénible, mais l'utilisation, la modification, la redistribution etc. sont possibles (mais sous forme source). C'est un cas (assez rare finalement) de logiciel libre avec une licence très restrictive par rapport aux licences habituelles.
Amha c'est bien libre, mais c'est typiquement le genre de particularité qui serait « fortement déconseillée » en annexe des définitions du libre (que ce soit FSF, OpenSource, DFSG...)
[^] # Re: Le fork: enfin libre?
Posté par Anonyme . Évalué à 1.
Pas évident du tout. Un logiciel est un tout.
Et si une partie, rien qu'un fichier, n'est pas libre, le logiciel n'est pas *vraiment* libre.
[^] # Re: Le fork: enfin libre?
Posté par #3588 . Évalué à 2.
Et si une partie, rien qu'un fichier, n'est pas libre, le logiciel n'est pas *vraiment* libre.
Pour ça, je suis tout à fait d'accord. Le moindre élément non libre d'un ensemble rend cet ensemble non libre (d'où les trolls sans fin sur SuSE).
Mais ici, si j'ai bien compris, tous les fichiers sont libres. Ils ont cependant une restriction peu fréquente, qui est que la distribution doit etre faite sous forme source, et non sous forme binaire. C'est une exigence technique de distribution qui n'entrave aucune des 4 libertés.
C'est un peu comme l'interdiction de modifier les sources autrement que par patches séparés (distribuer un travail dérivé sous forme source originale + patch). C'est une restriction importante, mais les 4 libertés sont respectées, et ce type de restriction est toléré par la FSF comme par l'OSI (c'est explicite sur les sites) bien que ce soit en même temps fortement déconseillé.
Amha, exiger la distribution sous forme source est une restriction du meme type. (mais il y a peut-etre d'autres restrictions que j'ai oubliées? je ne parle que de cette exigence).
C'est pas que je souhaite absolument placer ce logiciel dans la catégorie 'logiciel libre', je trouve aussi que la restriction est excessive, et assez pénible. Conseiller de recompiler soi-meme serait largement suffisant, et les distribs peuvent faire de très nombreux packages avec telles et telles optimisations... Mais ça me parait simplement respecter les 4 libertés, intégralement, meme si on est habitué à des licences plus souples.
[^] # Re: Le fork: enfin libre?
Posté par Éric (site web personnel) . Évalué à 10.
Et pleins de fichiers sans licence affichée, ce qui a l'air de poser contestation pour le fork justement
Sous forme de sources, elles sont legalement assemblees, mais pas la redistribution de la version binaire ne l'est pas
C'est leur version, et c'est tres contestable (et contesté sur la ML d'ailleurs). Leur argument c'est que mplayer n'est pas un programme mais une collection de sources. Donc les clauses "contaminantes" de GPL s'applicant aux programes ne s'apliquent pas là.
Perso je ne suis pas convaincu, une collection de sources prévues et rassembler en un endroit, avec d'autres sources pour pouvoir tout compiler ensemble (meme s'il n'y avait que un makefile, mais là il y a tout un "programme" en code source liant le tout), le tout avec de plus un nom, des screenshots et tout le tatoin peut bien etre considéré comme un programme. Surtout que c'est destiné à la compilation. Meme si c'est légal (à mon avis ca ne l'est pas) c'est très limite comme raisonnement, et permettrait alors la redistribution de code GPL mélé à du code non libre (par exemple non librement redistribuable) sous forme de code source (sous entendu la GPL serait compatible avec n'importe quoi, meme du non libre, tant qu'on ne distribue que les sources).
De plus ils recommandent la compilation "a la main"
Mouais ca c'est aussi pour justifier à postériori le fait de ne pas pouvoir donner de binaire. Car proposer un binaire n'a jamais empecher quelqu'un de compiler les sources disponnible à coté s'il le veut.
[^] # Re: Le fork: enfin libre?
Posté par Guillaume ARTUS . Évalué à 10.
Disons que la distribution binaires de MPlayer se heurte a quelques problemes juridiques:
http://www.mplayerhq.hu/DOCS/users_against_developers.html#binary(...)
Mais la volonte des auteurs est quand meme de retrouver le droit chemin de la GPL pour les prochaines versions.
Ici, le fork aura peut-etre l'avantage d'etre libre pour de vrai? Enfin presque: tant que les divx necessitent les codecs non libres de windows, les lecteurs multimedias compatibles divx ne seront pas a la fois 100% libres et 100% fonctionnels.
La c'est un point qui n'est plus vraiment valable, en utilisant les codec de ffmpeg ( http://ffmpeg.sourceforge.net/#formats(...) ), on peut quasiment rester GPL au niveau des codecs. En plus la rumeur veut que la libavcodec de ffmpeg soit plus rapide/moins gourmande/moins x86 que l'utilisation des ddls windows.. alors pourquoi se priver ?
[^] # Re: Le fork: enfin libre?
Posté par Prosper . Évalué à 3.
et du divx4 natif ? , parce que maintenant il n est plus indispensable de passer par les dll windows.
http://www.divx.com(...)
[^] # Re: Le fork: enfin libre?
Posté par Guillaume ARTUS . Évalué à 10.
On reste donc dans le debat : "Comment faire pour pouvoir sortir des binaires de mplayer"
[^] # Re: Le fork: enfin libre?
Posté par Serge Rossi (site web personnel) . Évalué à 7.
http://www.videocoding.de/(...)
C'est de l'open source mais c'est un mélange entre la OpenDivX license et la license GPL pour les évolutions (c'est expliqué sur leur home page).
D'ailleurs, MPlayer n'est pas qu'un excellent player, ça commence aussi à être un encodeur intéressant avec mencoder (qui se compile et s'insalle en même temps que mplayer).
Mais bon, pour l'instant, pour ce usage, je préfère encore transcode :
http://www.theorie.physik.uni-goettingen.de/~ostreich/transcode/(...)
[^] # Re: Le fork: enfin libre?
Posté par zeb . Évalué à 3.
Mais depuis le DivX5 montre sa superiorite (mais c'est vrai, pas dans toutes les conditions) grace a l'apport des B-Frames (un nouveau type d'intra-frame qui tient compte de la precedente et de l'interframe suivante) qui ameliorent la qualite pour la meme taille. Ces B-frames vont etre introduits prochainement dans le codec Xvid et comme ce codec a toujours ete superieur a celui de DivXNetworks, on peut esperer qu'il en sera de meme.
De plus, le divX5 ne marche pour l'instant que sous Windows, ou il installe un spyware (gator) pour payer les royalties mpeg4. Le moyen de desactiver le spyware est publie sur http://www.doom9.net(...) et son forum http://forum.doom9.net(...)
[^] # Re: Le fork: enfin libre?
Posté par Guillaume ARTUS . Évalué à 2.
bof:
mplayer : cvs d'aujourd'hui
ffmpeg : cvs d'aujourd'hui
.avi : recuperer sur http://www.divx.com/showcase/(...)
ligne de commande:
mplayer -vfm 5 xXx_DivX.avi
resultat:
[...]
Trying to force video codec driver family 5 ...
Opening Video Decoder: [ffmpeg] FFmpeg's libavcodec codec family
[...]
Start playing...
This file was encoded with DivX500 Build410
hmm, i havnt seen that version of divx yet, lets assume they fixed these bugs ..
[...]
Bin oui c'est joli de Divx5 sous linux avec un codec GPL ;-)
Tus
[^] # Re: Le fork: enfin libre?
Posté par William Steve Applegate (site web personnel) . Évalué à 2.
Ah oui, et au fait, les gusses de videocoding.de (le projet XviD) ont repris le code du Project Mayo, seules leurs modifs sont sous GPL. Autrement dit, ce n'est pas libre. Bref, encore un projet qui ne va pas dans la bonne voie...
Envoyé depuis mon PDP 11/70
[^] # Re: Le fork: enfin libre?
Posté par zeb . Évalué à 2.
J'essaierai d'en savoir plus la-dessus.
# Mauvais lien
Posté par Brice Favre (site web personnel) . Évalué à 5.
[^] # Re: Mauvais lien
Posté par Benoît Sibaud (site web personnel) . Évalué à -6.
Concernant le deuxième lien, l'erreur SQL est a priori un bogue daCode.
[^] # Re: Mauvais lien
Posté par gle . Évalué à 0.
A corriger par un modérateur qui passera par là...
[^] # On a essayé et on a eu des problèmes.
Posté par Brice Favre (site web personnel) . Évalué à -4.
[^] # Re: Mauvais lien
Posté par Benoît Sibaud (site web personnel) . Évalué à -3.
# en esperant que ca va ameliorer les choses...
Posté par Lecoeur Loïc . Évalué à 9.
j'espère que ce fork va améliorer les choses...
allez hop, apres une petite compilo (si ca marche !) on sera fixé.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: en esperant que ca va ameliorer les choses...
Posté par Lecoeur Loïc . Évalué à 5.
50% de cpu sur mplayer
60% de cpu sur mplayerxp, tout en affichant des **** INTERNAL FATAL ERROR ****** de partout.
acceleration xvideo, cpu VIA Samuel 2 @ 650 Mhz
bref, pas encore convaincu...
bon, c'est une version alpha de chez alpha, comme le montre le numéro de version (0.0.0)
[^] # Re: en esperant que ca va ameliorer les choses...
Posté par Yannick (site web personnel) . Évalué à 2.
Faudrait peut-être que je passe de oss a alsa non ?
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pq pas faire une option à la compilation ?
Posté par Éric (site web personnel) . Évalué à 10.
l'option était -xp (avec on avait un mplayer en thread, sans un mplayer avec l'ancien noyeau)
Il y a aussi un beau troll sur les licences dans la ML suite à ca. Celui qui fait le fork voulant mettre en GPL et le code de mplayer étant assez flou sur les licences (pas sur que ca soit trs légal actuellement mplayer, leurs arguments me paraissent légés)
# dommage
Posté par rouge13 . Évalué à 10.
Le site de MplayerXP est plus soft et l'auteur ne crache pas sur son collègue ...
# [hs] xp
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
Plus personne n'a d'imagination que tout le monde se sent obliger de pomper dans les ressources marketing des autres?
[^] # Re: [hs] xp
Posté par Lecoeur Loïc . Évalué à 1.
# threads
Posté par Francois Revol (site web personnel) . Évalué à 10.
Comme on l'a déja dit l'utilisation de threads permet de découper un programmes en unités d'exécution parallèles. Un programme n'est pas plus rapide, (même moins puisqu'il y a + de changements de contexte), mais il sera plus réactif, par exemple le GUI fonctionnera encore pendant le chargement du fichier. Le problème étant bien sur un découpage intelligent (pas si évident que ça à faire), et la synchronisation de tout ça...
Sous BeOS par exemple, on est obligé d'avoir au moins un thread par fenêtre (en plus du thread principal), donc si une fenetre bloque, le reste fonctionne toujours (si le programme est bien écrit...) (et même on peut débuguer un thread tout en utilisant toujours les autres comme si de rien n'était, par exemple il arrive qu'app_server (l'interface graphique) plante, dans ce cas, le noyau crée un thread supplémentaire chargé de dialoguer avec le débugueur, et un dialogue est affiché, mais les autres threads fonctionnent encore, et tant qu'on ne ferme pas le dialogue ça roule :-)) De même l'explorateur (Tracker) peut planter dans une fenetre, qu'à cela ne tienne, on la met de côté et on continue.
C'est une force, mais aussi une faiblesse, car ça complique fortement le portage d'application non-multithread (venant d'UNIX), car cela impose de sérialiser les actions des threads de gestion des fenetres.
Le principal problème à mon avis des threads sous Linux est le même que sous UNIX: l'API
j'ai déja vu du code pthread... c'est affreux.
Par comparaison BeOS est enfantin à programmer (encore faut-il savoir ce qu'on fait) (et non à ce niveau là c'est du C pur, puisque ça touche au noyau).
Pour ce qui est des avantages au niveau multimédia, il est clair que c'est intéressant sur les points suivants:
- avec une bécane SMP (qq1 m'en offre une à Pâques ?), autrement on a 100% d'un CPU, les autres ne font rien, et la vidéo est sacadée, mais on peut rien faire, puisque c'est monolithique,
- au niveau de l'architecture, il est plus élégant et plus logique d'avoir un thread de décodage video, un décodage audio, un extraction fichier... ça évite d'avoir une construction du type boucle d'évènement, d'utiliser des trucs du genre select() ou poll()... par exemple pendant que l'extracteur de fichier attend un secteur du disque, on peutfaire du décodage... Egalement ça permet d'assigner des priorités différentes à chaque thread, par exemple on dit que l'audio est + important que la video (on peut dropper une frame sans que ça se voit si cpuload>100%, mais avoir une cassure dans le son c + génant), alors qu'avec un truc monolithique, si on veut pas de glitch -> prio élevée, mais vu que le décodage vidéo prend énormément de ressources et qu'on l'a mis aussi en prio élevée -> le GUI ne répond plus.
ffmpeg: c'est clair que c'est plus rapide que les codecs en DLL... et le développement des codecs (qui ne sont pourtant qu'une partie de ffmpeg) avance à grand pas... la mailing liste est en ce moment à + de 5 message par jour (y a que 3 ou 4 qui contribuent bcp, le reste étant occasionnel).
Je rappelle également que ffmpeg justement c'est _aussi_ un convertisseur de fichiers ((open)divx, mpeg1, 2, ...ASF (mais pas WMA), .rm ...) Le seul reproche c'est qu'il encode pas encore en mp3 (juste mp2, et encore y a un patch pour utiliser lame), et qu'il manque aussi le support ogg.
[^] # formats ffmpeg
Posté par Francois Revol (site web personnel) . Évalué à 1.
http://www.geocrawler.com/lists/3/SourceForge/13077/100/8082565/(...)
[^] # Re: formats ffmpeg
Posté par Francois Revol (site web personnel) . Évalué à -2.
pour une fois que j'ai pas mis le mot BeOS dans un de mes postes je me fais déscorer !?
[^] # Re: formats ffmpeg
Posté par nodens . Évalué à -2.
Bon, -1, a bas les xp ! (euh non, je déconne)
[^] # Re: formats ffmpeg
Posté par Francois Revol (site web personnel) . Évalué à -2.
Et vu que le patch n'a pas encore été intégré (faudrait encore faire des tests, d'ailleurs si ça vous dit...), je donnais juste un pointeur au cas ou.
[^] # hmmm je devrais écrire des bouquins moi...
Posté par Francois Revol (site web personnel) . Évalué à -1.
# canne you spique frène-tcheu ?
Posté par homoanonymus . Évalué à 1.
Un peu d'explication des termes serait bienvenue !
Car tout le monde ne sais pas ce que signifie "multi-thread" ou "threadé" ou "forké"
(quoiqu'on devine le sens de fork dès le debut de la news)
Dans les commentaires, c'est pas beaucoup plus clair :
...Le surcoût engendré par le scheduling entre les différents threads ...
Alors pitié pour les non-initiés, on veut pas être exclus ! (surtout que c'est une news première page)
[^] # Re: canne you spique frène-tcheu ?
Posté par Francois Revol (site web personnel) . Évalué à 4.
thread = processus léger = processus qui partage son espace d'adressage anec un autre, ainsi que le contexte (descripteurs de fichiers...) (les processus, au moins sous UNIX sont normalement chacun dans un espace d'adressage virtuel différent) Il y a 2 façons de gérer des threads, la façon Linux (1-to-1), on prend un PID par thread, et on le gèrenet comme des processus (sauf que certaines parties du contexte sont communes) et le n-to-1 (type BSD) ou l'ordonancement des threads est fait en mode utilisateur à l'interieur même d'un processus.
pthread = lib standard (POSIX) pour utiliser des threads
multithreadé = programme créant plusieurs threads pour faire des choses en même temps.
[^] # Re: canne you spique frène-tcheu ?
Posté par nodens . Évalué à 1.
Scheduling : Partage du temps processeur entre les processus par le noyau. En effet, on dit linux multi-tâche, mais ce n'est qu'une illusion : un processeur ne peut effectuer qu'une opération à la fois. Donc, l'un des rôle clef du noyau est de "distribuer" le temps processeur. Comme les pains au chocolats à la récré. Enfin, pour ceux qui ont de la chance :)
[^] # Re: canne you spique frène-tcheu ?
Posté par Anonyme . Évalué à -1.
Il me semble que le but de l'excercice n'était pas d'expliquer en détail chaque terme.
Il me semble qu'il vous était tout simplement demandé d'employer les termes français.
Quand on vous demande de traduire email, on ne vous demande pas une définition générale du courrier électronique. On vous demande tout simplement de dire "courriel" ou courrier électronique. Ce qui, dans la plupart des cas, évite d'avoir à détailler le sens du mot.
[^] # Re: canne you spique frène-tcheu ?
Posté par Francois Revol (site web personnel) . Évalué à 0.
Effectivement le terme fork peut préter à confusion, vu qu'il est employé ici dans 2 sens différent (appel système et dédoublement du projet).
pour "threadé" on pourrait dire "fortement parallèle", ou "utilisant des processus légers" ou encore "parallélisée" (mais ça n'a pas tout à fait le même sens, ça ne dit pas si c'est tout sur le même CPU ou pas)
[^] # Re: canne you spique frène-tcheu ?
Posté par homoanonymus . Évalué à 2.
Si, si, ils ont compris, je demandais une explication des termes.
Quand à employer les termes francais, c'est pas toujours la panacée, mieux vaut un terme anglais que l'on ne connais pas (et donc on cherche à savoir) qu'un terme mal traduit qui induit en erreur.
Merci à tous...
[^] # Re: canne you spique frène-tcheu ?
Posté par boubou (site web personnel) . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.