Puis-je réinitialiser un client Web après un appel?

Voici l'exemple hypothétique:

WebCleint wc = new WebClient();

wc.DownloadStringCompleted += wc_DownloadStringCompleted;

wc.DownloadStringAsync(new Uri(callString));

wc = new WebClient();

wc.DownloadStringCompleted += wc_DownloadStringCompleted;

wc.DownloadStringAsync(new Uri(callString));

D'après ce que j'ai compris, le ramasse-miettes ne va pas attraper quelque chose jusqu'à ce qu'il soit complètement déréférencé. Je suppose donc que ma vraie question est la suivante: un enregistrement d’événement compte-t-il comme une référence à un objet?

Puis-je effectuer cet appel et demander aux deux déclarations de revenir par la même méthode?

J'ai beaucoup d'appels Web différents qui pourraient être faits. Ils doivent tous être effectués en async. Ils peuvent tous arriver à des moments aléatoires.

En ce moment, je suppose que la façon dont je l’ai construite empêche les appels simultanés, mais c’est un mauvais moyen de créer des choses haha.

J'essaie d'éviter de créer une file d'attente de pile.

0
Oui, je veux juste dire que je vérifierais si le Web Client est occupé. Si c'est le cas, mettez l'appel sur une pile. Lorsque les clients ont terminé, ouvrez-le et lancez-le. Ce qui en soi est une solution facile. Cependant, les types de retour doivent être traités TRES différemment, de sorte qu'il s'agirait d'une tonne de code personnalisé pour chacun.
ajouté l'auteur Anthony Russell, source
Oui, je veux juste dire que je vérifierais si le Web Client est occupé. Si c'est le cas, mettez l'appel sur une pile. Lorsque les clients ont terminé, ouvrez-le et lancez-le. Ce qui en soi est une solution facile. Cependant, les types de retour doivent être traités TRES différemment, de sorte qu'il s'agirait d'une tonne de code personnalisé pour chacun.
ajouté l'auteur Anthony Russell, source
Oui, je veux juste dire que je vérifierais si le Web Client est occupé. Si c'est le cas, mettez l'appel sur une pile. Lorsque les clients ont terminé, ouvrez-le et lancez-le. Ce qui en soi est une solution facile. Cependant, les types de retour doivent être traités TRES différemment, de sorte qu'il s'agirait d'une tonne de code personnalisé pour chacun.
ajouté l'auteur Anthony Russell, source
@ I4V c'est compliqué ... lol Je préfère ne pas entrer dans l'application mais il y a une bonne raison pour laquelle il est structuré de cette façon. Je veux juste arrêter les cas marginaux d'appels simultanés.
ajouté l'auteur Anthony Russell, source
@ I4V c'est compliqué ... lol Je préfère ne pas entrer dans l'application mais il y a une bonne raison pour laquelle il est structuré de cette façon. Je veux juste arrêter les cas marginaux d'appels simultanés.
ajouté l'auteur Anthony Russell, source
@ I4V Pas comme ci-dessus, juste pour être clair. C'était juste une hypothèse.
ajouté l'auteur Anthony Russell, source
@ I4V Pas comme ci-dessus, juste pour être clair. C'était juste une hypothèse.
ajouté l'auteur Anthony Russell, source
@ I4V Pas comme ci-dessus, juste pour être clair. C'était juste une hypothèse.
ajouté l'auteur Anthony Russell, source
file d'attente de pile ??
ajouté l'auteur I4V, source
file d'attente de pile ??
ajouté l'auteur I4V, source
@AMR OK, mais je veux vraiment entendre la bonne raison pour laquelle il est structuré de cette façon
ajouté l'auteur I4V, source
@AMR OK, mais je veux vraiment entendre la bonne raison pour laquelle il est structuré de cette façon
ajouté l'auteur I4V, source
@AMR pourquoi voulez-vous utiliser le même WebClient? Créez-en un, téléchargez quelque chose et jetez-le. Quel est le problème avec ça? Vous pouvez également utiliser Tâches/Sujets pour créer ses propres WebClients.
ajouté l'auteur I4V, source
@AMR pourquoi voulez-vous utiliser le même WebClient? Créez-en un, téléchargez quelque chose et jetez-le. Quel est le problème avec ça? Vous pouvez également utiliser Tâches/Sujets pour créer ses propres WebClients.
ajouté l'auteur I4V, source
@AMR pourquoi voulez-vous utiliser le même WebClient? Créez-en un, téléchargez quelque chose et jetez-le. Quel est le problème avec ça? Vous pouvez également utiliser Tâches/Sujets pour créer ses propres WebClients.
ajouté l'auteur I4V, source
Je pense qu'il veut dire un gestionnaire de files d'attente pour télécharger des chaînes et garder une trace de chaque téléchargement dans une file d'attente.
ajouté l'auteur J. van Langen, source
Je pense qu'il veut dire un gestionnaire de files d'attente pour télécharger des chaînes et garder une trace de chaque téléchargement dans une file d'attente.
ajouté l'auteur J. van Langen, source

6 Réponses

Chaque enregistrement d'événement gardera l'objet (WebClient) actif, à moins que votre instance actuelle (l'instance contenant le wc_DownloadStringCompleted) ne soit libérée. Vous pouvez désenregistrer l'événement dans wc_DownloadStringCompleted. Pour obtenir le WebClient d'origine dans le fichier wc_DownloadStringCompleted, utilisez l'objet expéditeur.

public void wc_DownloadStringCompleted(object sender, EventArgs e)
{
    WebClient  wc = (WebClient)sender;

    wc.DownloadStringCompleted -= wc_DownloadStringCompleted;

   //handle download completed
}
1
ajouté
Tu as raison Patrick
ajouté l'auteur J. van Langen, source
C'est vrai, wc détient la référence. Le GC ne se soucie pas du nombre de références qu'un objet contient, mais du nombre de références à cet objet.
ajouté l'auteur Patrick Hallisey, source
Dans ce cas, wc est l'éditeur d'événements. Quel que soit le nombre de gestionnaires d’événements enregistrés pour les événements de wc, c’est celui-ci qui contient la référence aux abonnés.
ajouté l'auteur Patrick Hallisey, source

Chaque enregistrement d'événement gardera l'objet (WebClient) actif, à moins que votre instance actuelle (l'instance contenant le wc_DownloadStringCompleted) ne soit libérée. Vous pouvez désenregistrer l'événement dans wc_DownloadStringCompleted. Pour obtenir le WebClient d'origine dans le fichier wc_DownloadStringCompleted, utilisez l'objet expéditeur.

public void wc_DownloadStringCompleted(object sender, EventArgs e)
{
    WebClient  wc = (WebClient)sender;

    wc.DownloadStringCompleted -= wc_DownloadStringCompleted;

   //handle download completed
}
1
ajouté
Tu as raison Patrick
ajouté l'auteur J. van Langen, source
C'est vrai, wc détient la référence. Le GC ne se soucie pas du nombre de références qu'un objet contient, mais du nombre de références à cet objet.
ajouté l'auteur Patrick Hallisey, source
Dans ce cas, wc est l'éditeur d'événements. Quel que soit le nombre de gestionnaires d’événements enregistrés pour les événements de wc, c’est celui-ci qui contient la référence aux abonnés.
ajouté l'auteur Patrick Hallisey, source

Chaque enregistrement d'événement gardera l'objet (WebClient) actif, à moins que votre instance actuelle (l'instance contenant le wc_DownloadStringCompleted) ne soit libérée. Vous pouvez désenregistrer l'événement dans wc_DownloadStringCompleted. Pour obtenir le WebClient d'origine dans le fichier wc_DownloadStringCompleted, utilisez l'objet expéditeur.

public void wc_DownloadStringCompleted(object sender, EventArgs e)
{
    WebClient  wc = (WebClient)sender;

    wc.DownloadStringCompleted -= wc_DownloadStringCompleted;

   //handle download completed
}
1
ajouté
Tu as raison Patrick
ajouté l'auteur J. van Langen, source
C'est vrai, wc détient la référence. Le GC ne se soucie pas du nombre de références qu'un objet contient, mais du nombre de références à cet objet.
ajouté l'auteur Patrick Hallisey, source
Dans ce cas, wc est l'éditeur d'événements. Quel que soit le nombre de gestionnaires d’événements enregistrés pour les événements de wc, c’est celui-ci qui contient la référence aux abonnés.
ajouté l'auteur Patrick Hallisey, source

Similaire à cette question:

Les gestionnaires d'événements arrêtent-ils la récupération de place?

Il semblerait que les éditeurs, wc dans ce cas, ne voient pas leur récupération de place affectée. wc contient une référence au gestionnaire d'événements, mais rien ne contient une référence à wc.

1
ajouté
Je n’ai donc pas peur de dire que c’était une excellente réponse, mais un peu au-dessus de ma tête. Est-il en train de dire que si votre éditeur (wc dans ce cas) détient une référence à un gestionnaire d'événements, il l'exécutera une fois puis sera collecté?
ajouté l'auteur Anthony Russell, source
Alors, quand vous dites: PEUT rester en vie, cela signifie-t-il qu'il y a une chance qu'il maintienne une référence et qu'il soit toujours disposé?
ajouté l'auteur Anthony Russell, source
Il existe de nombreuses références au Web Client en interne par les méthodes Download {Action} Async, mais ces références relèvent du domaine de l'implémentation non documentée. D'après ce que je peux dire, les appels internes assez complexes des méthodes de requête asynchrone sur WebClients contiendront des références au WebClient. Si vous créez un client Web et effectuez un appel asynchrone, il doit rester actif grâce à ses propres objets et références internes. Mais cela dépend de la mise en œuvre interne d'une classe de framework pour toujours avoir les mêmes effets secondaires.
ajouté l'auteur Patrick Hallisey, source
Rien n'empêche la collecte de wc avant le déclenchement de l'événement, à l'exception des éléments internes de WebClient. Si DownloadStringAsync crée une référence interne au client Web, il peut rester en vie suffisamment longtemps pour déclencher l'événement.
ajouté l'auteur Patrick Hallisey, source

Similaire à cette question:

Les gestionnaires d'événements arrêtent-ils la récupération de place?

Il semblerait que les éditeurs, wc dans ce cas, ne voient pas leur récupération de place affectée. wc contient une référence au gestionnaire d'événements, mais rien ne contient une référence à wc.

1
ajouté
Je n’ai donc pas peur de dire que c’était une excellente réponse, mais un peu au-dessus de ma tête. Est-il en train de dire que si votre éditeur (wc dans ce cas) détient une référence à un gestionnaire d'événements, il l'exécutera une fois puis sera collecté?
ajouté l'auteur Anthony Russell, source
Alors, quand vous dites: PEUT rester en vie, cela signifie-t-il qu'il y a une chance qu'il maintienne une référence et qu'il soit toujours disposé?
ajouté l'auteur Anthony Russell, source
Il existe de nombreuses références au Web Client en interne par les méthodes Download {Action} Async, mais ces références relèvent du domaine de l'implémentation non documentée. D'après ce que je peux dire, les appels internes assez complexes des méthodes de requête asynchrone sur WebClients contiendront des références au WebClient. Si vous créez un client Web et effectuez un appel asynchrone, il doit rester actif grâce à ses propres objets et références internes. Mais cela dépend de la mise en œuvre interne d'une classe de framework pour toujours avoir les mêmes effets secondaires.
ajouté l'auteur Patrick Hallisey, source
Rien n'empêche la collecte de wc avant le déclenchement de l'événement, à l'exception des éléments internes de WebClient. Si DownloadStringAsync crée une référence interne au client Web, il peut rester en vie suffisamment longtemps pour déclencher l'événement.
ajouté l'auteur Patrick Hallisey, source

Similaire à cette question:

Les gestionnaires d'événements arrêtent-ils la récupération de place?

Il semblerait que les éditeurs, wc dans ce cas, ne voient pas leur récupération de place affectée. wc contient une référence au gestionnaire d'événements, mais rien ne contient une référence à wc.

1
ajouté
Je n’ai donc pas peur de dire que c’était une excellente réponse, mais un peu au-dessus de ma tête. Est-il en train de dire que si votre éditeur (wc dans ce cas) détient une référence à un gestionnaire d'événements, il l'exécutera une fois puis sera collecté?
ajouté l'auteur Anthony Russell, source
Alors, quand vous dites: PEUT rester en vie, cela signifie-t-il qu'il y a une chance qu'il maintienne une référence et qu'il soit toujours disposé?
ajouté l'auteur Anthony Russell, source
Il existe de nombreuses références au Web Client en interne par les méthodes Download {Action} Async, mais ces références relèvent du domaine de l'implémentation non documentée. D'après ce que je peux dire, les appels internes assez complexes des méthodes de requête asynchrone sur WebClients contiendront des références au WebClient. Si vous créez un client Web et effectuez un appel asynchrone, il doit rester actif grâce à ses propres objets et références internes. Mais cela dépend de la mise en œuvre interne d'une classe de framework pour toujours avoir les mêmes effets secondaires.
ajouté l'auteur Patrick Hallisey, source
Rien n'empêche la collecte de wc avant le déclenchement de l'événement, à l'exception des éléments internes de WebClient. Si DownloadStringAsync crée une référence interne au client Web, il peut rester en vie suffisamment longtemps pour déclencher l'événement.
ajouté l'auteur Patrick Hallisey, source