Evenement thread AddHandler

bonjour a tous ;)

ma question est d'ordre général :?
en effet , je suis intrigue pour le système d’avidement sous vb.net ; j'ai créer une petite application ou j'ai implémenté des événements crées manuellement (des deux cote ) ; j'ai connecte un événement de la vue sur une class model
ex :
(AddHandler Me.event_lancement, AddressOf Mdl.parcourFichier)

ce qui me rend perplexe 8O est que une fois le signal est lance , la vue ce fige .
la vue attend la fin de traitement de la fonction appelle par l'évenemt pour se débloquer !!!?....
normalement une fois le "signal" lance, la fonction appelé doit être tourne en arrière plan ??!

je ne comprend pas ???

ps: a l'origine je suis développeur sous qt/c++. avec qt on a un système exactement a l'identique slot/signal , avec la gestion des threads
ps2: petite précision, je développe en wpf

Bonjour.

Le système d'événements n'a absolument rien à avoir avec la concurrence. C'est simplement une syntaxe commode pour enregistrer un callback. Ta méthode est donc exécutée sur le thread UI, c'est à dire sur le même thread que la pompe à messages de l'application. D'où ce gel.

Si tu veux réaliser l'opération de façon asynchrone, tu dois le spécifier explicitement, soit via une méthode xxxAsync (Stream.ReadAsync par exemple), soit via Task.Run. La première méthode est conseillée si tu as de nombreuses opérations IO concurrentes (la tâche sera associée à un IO completion port, ce qui permet à Windows d'optimiser l'ordre de lecture). Dans les deux cas ce sera l'occasion de te pencher sur le couple Async/Await. Pour faire simple : si ta méthode avait commencé sur le thread UI, après ton appel à "await Stream.ReadAsync()..." la méthode reprendra sur le thread UI.

bonjour DonQuiche

en effet c'est fascinant, depuis hier j'ai pas arrêté de lire des articles sur les threads :) 8-)

Citation:

---

Le système d'événements n'a absolument rien à avoir avec la concurrence. C'est simplement une syntaxe commode pour enregistrer un callback.

---

un simple pattern observer:P

Citation:

---

Dans les deux cas ce sera l'occasion de te pencher sur le couple Async/Await

---

apparemment c'est très récent comme méthode, la plupart des articles que j'ai lu n'ont parle même pas (les articles sont anciens peut être ).
je trouve que c'est une nouvelle façon de remplacer les BackgroundWorker (????)

ça m'a un peut déprimé de voir un langage (ou plutôt un framework) aussi évolué ne pas gérer le multitache en auto:calim2:.
je ne suis pas en train de ce plaindre, loin de la (surtout quand on est passionné par l'informatique ;):P).
le reste compense très bien surtout linq que je trouve très intéressant

ps :pc: : apparemment le Async/Await n'est implanter dans Visual studio que a partir du 2012 :aie:

Citation:

---

Envoyé par linke

un simple pattern observer

---

Bof. En essence, oui. Sauf que chaque événement est un observable et qu'une même instance peut-être l'observateur de plusieurs observables avec un code spécifique pour chaque. Au final ça demande moins de code et de pseudo-classes (même si les macros du C++ permettent de réduire significativement ce coût).

Mais bon, c'est bien un système de notifications "push" asynchrone en tout cas, si c'est ce que tu voulais dire.

Citation:

---

ça m'a un peut déprimé de voir un langage (ou plutôt un framework) aussi évolué ne pas gérer le multitache en auto

---

C'est au contraire une excellente chose pour moi. Je ne vois pas pourquoi tout devrait être asynchrone par défaut, ça n'a aucun sens à mes yeux : c'est beaucoup plus lourd à écrire (du fait de la synchronisation) et à exécuter (inscription dans un thread pool, synchronisation des caches processeur, parfois changement de contexte, etc). Et ce alors que l'UI synchrone par défaut fonctionne très bien et que les applis Windows sont parfaitement réactives.

Certes un univers purement asynchrone évite au programmeur débutant de bloquer par mégarde le thread UI. Et alors ? En comparaison il se retrouve maintenant à devoir manier des concepts bien plus complexes et à créer des race conditions (la gestion des états est difficile avec un système d'échanges de messages asynchrones). Sans parler du fait qu'au lieu d'avoir une UI bloquée, rien n'est visible et l'utilisateur va tenter de recliquer et ainsi enfiler N fois l'opération. C'est un choix très dangereux.

Je ne sais pas pourquoi les dévs de Qt, Gtk et autres ont fait ce choix. Y avait-il un problème propre au monde Unix qui rendait cela nécessaire? Ou était-ce un choix délibéré et, à mes yeux, maladroit, datant d'une époque où l'on avait encore trop peu d'expérience avec la concurrence pour savoir quand l'exposer ou non et comment ? En tous les cas je n'échangerais pas mon UI synchrone contre dix barils d'une UI asynchrone.

Citation:

---

apparemment c'est très récent comme méthode, la plupart des articles que j'ai lu n'ont parle même pas (les articles sont anciens peut être ).

---

En effet c'est une addition récente. Si tu utilises une version du langage plus ancienne, utiliser Task.ContinueWith en passant un argument un scheduler créé via TaskScheduler.FromCurrentContext pour forcer son exécution sur le thread UI (le "contexte de synchronisation" de l'UI).