[UDF] Une sorte de multi-threading!

[matwachich]

Salut à tous!

Alors voici un truc que j'utilise depuis belle lurette! mais ce n'est que maintenant que j'ai trouvé le temps (et l'envie!) de l'arranger un peut. La doc n'est pas super garnie, mais suffisante je pense.

Attention aux fonctions: _CoProc_Pause, et _CoProc_Resume, elle peuvent rendre le thread instable (lien)

Il y un exemple très bien structure (bien qu'un peut complexe au premier abord), et commenté.

PS: Régale toi mikell!

[lesolutionneur]

Sympa mais relance l'interpréteur en plusieurs fois dans différents thread processus donc horriblement pas optimisé !

[ZDS]

Pas mal, pas mal du tout

Juste une question, comment est-ce-que tu gères les accès concurrents? Et un autre truc me chagrine, les passages de messages sont en asynchrone, aurais-tu sous la main un exemple avec une communication synchrone?

Merci d'avance !

EDIT: Ouh la... je voulais juste me renseigner, pas la peine de devenir simili-agressif (triples ponctuations, pas un seul smiley pour y voir une pointe d'ironie, y a de quoi se poser des questions sur le ton que tu utilises) ^^ En fait, je travaillais aussi sur un système en distribué, et vu que je suis encore assez loin d'en avoir fini avec, je comptais m'inspirer de ton algo (sans pour autant faire de plagiat, je te rassure). Mais pour cela, j'avais besoin de faire des tests en synchrone et en asynchrone, je me demandais juste comment toi tu l'aurais gérer.
Pour ce qui est des accès concurrents, oui je pensais à un fichier de log par exemple, mais pas que ça. Si deux processus écrivent en même temps, ça peut f**tre la m**de. Idem, je pensais que tu avais une petite idée là-dessus.
Tant pis, je vais continuer sur ma lancée Merci quand même.

EDIT2: Je trouve son code plutôt propre au contraire. Le principe du multi-processus est justement d'avoir plusieurs processus: Le fait d'avoir le processus AutoIt.exe lancé à chaque fois ne se pose qu'avec un lancement en version source.

[matwachich]

Bon, j'ai bien dit: une SORTE de multi-threading!

Je ne gère rien de ce que vous demandez!!! Je n'en ai jamais eu besoin jusqu'à maintenant.
- Les accès concurrents? mais à quoi??? Au variables globales? Au fichiers??? Franchement, je ne me suis jamais poser la question!
- Les messages en asynchrone? Je suppose que ça veut dire que le thread attend confirmation du script père qu'il à bien reçu le message avant de continuer? Alors là, je n'en sais rien, peut être qu'avec des variables qui s'initialisent et à la réception et que le thread test avant de continuer.
Je pense que ça doit être simple à mettre en oeuvre, mais je ne compte pas le faire, sauf si j'en ai besoin un jour, car là, je suis sur autre chose...

Pas optimiser, surement, mais c'est pas fait non plus pour lancer un 100 aine de threads!!!

[lesolutionneur]

Ne t'énerve pas !
Je blâme les créateurs d'autoIt qu'en ont rien à faire et qui ne veulent pas ajouter le multithreading, ton UDF, lui, est pas mal et tu ne peux pas faire mieux, l'autoIt ne permet pas de faire du "vrai" multithreading.

Merci pour le partage !

[matwachich]

Mais non, je ne m'énerve pas!!!
Mais c'est vrai qu'on pourrait le penser parce que j'ai oublier de mettre ou bien , voir même

Je pense qu'il ne faut pas non plus blâmer les créateurs d'AutoIt, il voulait un truc simple, et c'est réussi! Après... You can't always get want you want!

[Iste]

Sympa mais relance l'interpréteur en plusieurs fois dans différents thread processus donc horriblement pas optimisé !

Etant la seule solution possible c'est au contraire tres propre de tout ranger dans un UDF bien construit.

Je blâme les créateurs d'autoIt qu'en ont rien à faire et qui ne veulent pas ajouter le multithreading

Vous devriez plutôt les remercier, car c'est bien en retirant ce genre de fonctionnalité qu'AutoIt peut rester facile d’accès a tous. C'est la même histoire que pour le goto !

@ZDS : Si deux process écrivent en même temps dans un fichier, c'est pas vraiment a l'udf de gérer ça, mais au dev qui écrit les fonctions de lecture/ecriture ou même au system ! Pour les variables d'environnement, je ne voie pas qui d'autre que l'OS pourrait gérer ça.
Ici l'udl se contente en effet de faire ce pour quoi il a été développé, lancer dans un autre thread un bout de code.

Bref, si vous voulez faire des choses plus avancées que ce pour quoi AutoIt est conçu, je vous recommande de vous tourner vers d'autre langages.
N'oubliez pas que si matwachich peut s'attaque régulièrement aux limites d'AutoIt, c'est surtout grâce a sa grande rigueur dans son code, et aussi surement un peu de temps a perdre ^^

@matwachich : Merci donc pour ce partage, encore une foi très intéressent et bien écrit !

[ZDS]

Bonjour,

Tout d'abord, j'ai tenté de développer un système en multiprocessus avec ton UDF, qui modélises 35 grandes villes (donc 35 processus), où chaque ville connait ses proches voisins et sait quelle distance les séparent, et un contrôleur central à qui on pose la question du plus court chemin par reversement. J'ai eu du mal (tu documentes pas beaucoup tes algos); mais j'y suis arrivé, et je suis assez bluffé. Ce n'est pas encore 100% fonctionnel, mais ce sont des bidouillages à faire de mon coté Bravo Matwachich ! Mais ça m'empèchera pas de tenter la même chose avec ma propre UDF ^^

Maintenant les réponses :

@Iste: L'UDF de Matwachich propose de passer des messages entre process. Un type d'accès concurrent (autre que le partage d'un fichier ou d'une ressource) est donc l'envoi simultané de messages depuis les processus A et B vers le processus C. Ma question était générale, ton argument s'appuye sur un exemple particulier. C'était aussi lié à ma seconde question sur les messages synchrones/asynchrones.

@lesolutionneur: "Je blâme les créateurs d'autoIt qu'en ont rien à faire" > Je trouve ta remarque assez déplacée, car justement l'équipe AutoIt nous a produit un langage avec des matériaux de base de très bonne qualité PLUS de nombreuses UDF basées sur ces fonctionnalités (Rien ne les empêchait comme dans d'autres langages de dire à grosses mailles "On a fait des Object, des Int, des String et des pointeurs; pour le reste, démerdez vous, vous pouvez faire des array en mettant des pointeurs bout à bout, vous pouvez faire des doubles en gérant deux ints à chaque fois, etc... Nous on s'en lave les mains"). Bref, j'appelle pas ça "n'en avoir rien à faire", bien au contraire.

@Iste: "[...] je vous recommande de vous tourner vers d'autre langages." > Pas d'accord. Ce n'est pas de l'utopie, AutoIt est tout simplement un langage performant sur des fonctionnalités primordiales, le reste n'est que de la déduction. Savoir comment marche l'addition permet de faire des multiplications, connaitre la multiplication permet de déduire les divisions et les puissances, les puissances entraînent les racines, et de là on part sur les complexes, etc... cet exemple de maths s'applique très bien à tout algo, quelque soit le langage.

Et même si matwachich déploie une certaine rigueur dans l'écriture de ses UDF, il n'en reste pas moins que rien n'est commenté au coeur des fonctions, génant quand elles s'étalent sur plusieurs pages :s Mais bon, on se débrouille toujours, donc pas de souci !

A bientôt !

EDIT @lesolutionneur: Toutes les UDFs que tu trouves dans "C:\Program Files\AutoIt3\Include", et que tu utilises sans vraiment chercher à comprendre en faisant #include <...>, sont en soit des fonctionnalités optionnelles comme tu les appelles.
Et puis, il faut comparer ce qui est comparable, AutoIt dans sa mouture actuelle date d'il y a plus ou moins 10 ans, alors que C++ est presque aussi âgé que moi. C'est juste que ce que tu prends pour des limitations d'AutoIt sont juste des fonctionnalités qui n'ont pas encore été codées. J'aimerai bien savoir où tu vois une limite là dedans, à part dans ta patience ^^

[lesolutionneur]

Euh, je ne vois pas en quoi ajouter des fonctionnalités optionnelles ferait devenir le langage plus compliqué !

Perso, je me suis mis au C++ : marre de toutes ces limitations (même si le langage est bien pratique pour faire un petit programme rapidemment)

[Iste]

@Iste: L'UDF de Matwachich propose de passer des messages entre process. Un type d'accès concurrent (autre que le partage d'un fichier ou d'une ressource) est donc l'envoi simultané de messages depuis les processus A et B vers le processus C. Ma question était générale, ton argument s'appuye sur un exemple particulier. C'était aussi lié à ma seconde question sur les messages synchrones/asynchrones.

L'UDF ne se charge pas lui même de transmettre ses messages, mais utilise les outil que le system lui offre. La gestion de ce genre de probleme n'est donc pas son probleme.
Cela n'aurait pas été le cas si les process avait discuté entre eux en TCP ou autre truc plus "a la main".
Donc même si je comprend bien le probleme ici, et que j'aimerai comme vous que le tout soit clairement géré, matwachich a été bien claire de toute façon, ca le gère pas et osef ^^

@Iste: "[...] je vous recommande de vous tourner vers d'autre langages." > Pas d'accord. Ce n'est pas de l'utopie, AutoIt est tout simplement un langage performant sur des fonctionnalités primordiales, le reste n'est que de la déduction. Savoir comment marche l'addition permet de faire des multiplications, connaitre la multiplication permet de déduire les divisions et les puissances, les puissances entraînent les racines, et de là on part sur les complexes, etc... cet exemple de maths s'applique très bien à tout algo, quelque soit le langage.

Heu oui en effet, a peut prés tout les langages savent faire des maths, mais pour ce qui est des contraintes technique, la on y peut juste rien !
Chaque langage a son domaine d'utilisation. En sortir un du sien, c'est soit expérimental, soit contraint, soit idiot !
Donc non, AutoIt n'est pas fait pour certaine choses et donc pour cela il faut changer de langage.

Pis c'est pas faux que les codes de matwachich sont pas commentés même si très complexes, mais comme ils sont propres, soit on a les compétences et ils sont tout a fait lisible, soit on les a pas et dans ce cas il faut accepté les principe de la programmation boite noire.
C'est vrai que c'est un peu dommage sur un forum d'entraide, mais de toute façon les sujet abordés sont en général loin du niveau débutant.

Mais tout n'est pas tout blanc non plus, d’ailleurs, matwachich, j'ai testé ces différent script sur du win7x64, et l'exemple de Messages.au3 ne fait rien au mieux, et me plante avec un "Line 4619 (...) error:Variable used without being declared." (et virer l'opt() ne change rien)
Pire, si je compile en x84, ça plante les scriptes receveurs !

Edit : @lesolutionneur
Ajouter ce genre de choses dans un langage c'est aussi risqué que d'ajouter une perceuse dans le bac a joués d'un enfant !
Ca pourrait lui etre tres utile, mais on est presque sur que si il s'en sert ca ne donnera rien de bon !!

[matwachich]

Waw!
- Déjà, un truc super important que j'ai oublier de mentionner: La base de l'UDF n'est pas de moi Cherchez CoProc sur le forum anglais, c'est un UDF un peu vieux, je l'ai un peut arranger, enlever un truc (que je pense inutile) et je l'ai adapter pour utiliser l'UDF messages.au3

- Après, pour le multi-threading (comme pour la POO) les dev on été claire: il ne seront jamais ajoutés!

- C'est vrai que je ne commente pas beaucoup , mais je suis un maniaque de l'organisation et de l'indentation, d'ou ces suggestions d’abréviations pour le prochain Scite4AutoIt! , Mais, dans mon (gros) projet actuel, je m'efforce de bien commenter!

- Enfin, pour le bug, j'utilise cet UDF depuis belle lurettes maintenant je n'en ai jamais eu! C'est peut être en rapport avec x64... franchement je sais pas

Ciao

[ZDS]

Ok merci pour les infos, donc pour mes questions, je pense que c'est Picasso du forum US qui pourra me répondre, désolé de t'avoir fait ch** avec ça. (Iste, tu avais tort, c'est bien l'UDF qui traite le passage de messages en créant des fenêtres invisibles).

Sinon, par rapport au bug, j'essaye aussi de le reproduire, mais ça fonctionne sur XP 32, XP 64, Vista 32, et Seven 64 (pas eu le temps de tester sur les autres, mais je peux le faire sur des VMs au pire). Je pense pas que ça vienne de ton OS, ou alors pas étonnant que ça plante si tu réussis à compiler en x84 ^^

[Iste]

Iste, tu avais tort, c'est bien l'UDF qui traite le passage de messages en créant des fenêtres invisibles

Oui ca j'ai bien vu, et bien qu'étrange c'est plutôt malin, mais pour envoyer les infos a une fenêtre, il faut bien passer par le system !
Bon je sais, en tcp aussi, mais la on est quand même bien plus dépendant et impuissant.

Et sinon, oui je fait bien du x86 xD
Mais même après avoir tout essayer je n'ai pas réussi a avoir le moindre code fonctionnel. (plantage ou bug a chaque fois)

Donc bon, si ca marche chez vous c'est bien que le souci vient de moi, mais je n'arrive pas a l'isoler :s

[matwachich]

Moi aussi je suis sur x86 (Vista) et ça marche comme sur des roulettes!
Tu peut nous montrer ton code, on sait jamais...

[Iste]

J'ai utilisé celui de l'exemple de message.au3, sans plus sans moins

[matwachich]

Héhé! c'est pas un bug!
C'est parce que vous avez (comme moi) juste décommenté l'exemple, et vous l'avez lancer directement dans le fichier Message.au3

Alors que, si on regarde bien, des variables (le array $msgId) sont déclarées APRES l'exemple, d'ou le Variable not déclared.

Il faut prendre le script d'exemple, le mettre dans un fichier séparé, compiler et lancer, et ça roule ma poule!!!

[Iste]

Et c'est bien ce que j'ai fais, un petit test.au3 a coté tout comme il faut !
Mais encore une foi, ca "marche", j'ai juste un plantage total du process qui doit récup le message au moment de l'envoi

[matwachich]

Ew...
Moi ça envoi normalement
Je sèche

[mikell]

XP SP3 x86 => marche normalement avec un test.au3 compilé