Version imprimable
Je pense que je vais utiliser les 2, QueueUserWorkItem et une Queue.Citation:
Envoyé par Kaidan
L'automate est un automate programmable industriel avec lequel la DLL va communiquer en utilisant un port série.
Penses-tu qu'il faut un thread supplémentaire pour déclencher les threads du pool, ou la fonction déclenchée lors de l'appel de la DLL peut-elle se charger de déclencher les threads du threadpool ?
Si l'hôte de la DLL ne fait QUE réceptionner les requêtes et les mettre dans le ThreadPool pour ajout dans la queue de requêtes, autant utiliser le thread de l'application. Si il fait d'autres choses (gérer Start / Stop), interagir avec la Console etc. mieux vaut utiliser un autre thread.
Le Thread chargé de prendre les requêtes dans la Queue et les envoyer à l'automate fonctionnera en permanence, donc je pense que ce sera le thread de l'application.Citation:
Envoyé par Kaidan
Le thread réceptionnant les requêtes et les placant dans la queue ne ferait que ca, s'il en faut un.
Qu'en penses-tu ?
A mon avis, le mieux est de conserver le thread principal pour pouvoir le killer au besoin et envoyer un message à tous les autres threads pour dire "on arrête d'écouter, on envoie tout et on ferme" histoire de quitter proprement. Lors de l'intialisation du programme, tu peux créer le thread qui se charge d'accepter les requêtes entrantes et le thread qui se charge de poller la queue de d'envoyer à l'automate.
Je pense que tu as raison. Le thread principal crée tous les autres threads et les termine lorsqu'il faut arrêter tout.Citation:
Envoyé par Kaidan
Je vais essayer comme ca.
Bonjour,
J'ai une question au sujet de ma DLL.
Cette DLL contient un fichier program.cs, ce fichier contient une fonction Main. Quelqu'un sait-il quand cette fonction Main sera exécutée ? est-ce lors du premier appel d'une fonction de la DLL ?
A quel thread appartient cette fonction Main ? à un thread propre à la DLL ?
Autre question : cette DLL contient une fonction PORT1_DataReceived qui est déclenchée sur l'événement DataReceived d'un port COM. A quel thread appartient cette fonction ?
Merci d'avance pour vos réponses.
Salut Levalp,Citation:
Envoyé par levalp
le main d'une DLL (un assembly compilé comme bibliotheque de classe j'entends) n'est jamais executé implicitement, une DLL ne demarre pas, et n'est pas executé, c'est un recueil de classe, point.
Si tu parles de ce DataReceived, c'est indiqué que le callback sera traité par un thread du pool (comprendre un thread quelconque).
Salut,Citation:
Envoyé par SirJulio
Je ne comprends pas bien, car le Main de ma DLL va lancer un thread, donc ce code doit bien être exécuté quelque part ?
Concernant le DataReceived, je lis : "L'événement DataReceived est déclenché sur un thread secondaire lorsque des données sont reçues de l'objet SerialPort. Cet événement étant déclenché sur un thread secondaire et non sur le thread principal,..."
mais vu que pour moi c'est dans une DLL, dois-je comprendre qu'il s'agit dans mon cas du thread principal du programme appelant la DLL ?
merci d'avance
Une DLL en .Net n'a pas à avoir de Main.Citation:
Envoyé par levalp
Comme l'ont indiqué SirJulio et BlueDeep, et je me permet d'insister parce que tu fais plusieurs fois la confusion dans cetet discussion, une DLL n'est qu'un ensemble de classes mises ensemble dans un même fichier ; ça n'a aucun rapport avec le concepts de thread, événement, AppDomain, etc. Ton problème (gestion de threads, Threadpool, etc.) serait strictement le même si ton code était entièrement compris dans une même assembly.
Salut Levalp,
pour etre plus explicite, vu qu'une DLL ne peut, structurellement, pas etre demarré (executé), c'est forcement un exe (console, windows whatever) qui va l'appeler. De fait, la problematique de threading est reporté vers cette assembly tierce (qui appelle, et comment ?). Simplifions le cas à l'"extreme :
-j'ai un exe console qui appelle des methodes de ma DLL.
-une DLL avec des methodes
si j'appelle ma methode de ma DLL en la threadant depuis mon appli alors l'appel se fera sur un thread tiers (poolé ou non). A contrario, si j'appelle ma methode directement, l'appel se fera sur le thread ayant demarré mon appli (qu'on pourrait appeler le thread principal).
Que ta DLL contienne ou non un main ne change pas le probleme (une dll peut avoir un main ce n'est pas interdit juste inutile), un assembly compilé en /out:Library (donc ce qu'on appelle une DLL) ne peut pas etre demarré, il sera juste parcouru par les autres assemblies faisant des appels dessus.
Pour le Datareceived, je ne sais pas trop comment ca marche, mais j'imagine que tu dois initialiser la classe et la classe emet des events (datareceived ici) quand elle entends quelque chose. Les callbacks de ces events seront executés par un thread du pool (au meme titre qu'un timer si tu veux, tu init un timer les callback d'elapsed sont levés par un thread tiers).
Bref, dans une DLL, si cette derniere ne créé pas explicitement de thread (new thread blabla) ou implicitement (le datareceived par exemple, mais aussi des methodes async quelconque), la problematique du thread est reporté vers l'appelant.
En esperant avoir ete plus clair. =)
Citation:
Envoyé par Bluedeep
Bonjour Bluedeep et Guulh,Citation:
Envoyé par Guulh
Merci pour ces précisions. je crois que maintenant j'ai compris comment ca fonctionne.
Salut SirJulio,Citation:
Envoyé par SirJulio
C'est plus clair, en effet. Merci pour tes précisions.