ThreadPool.QueueUserWorkItem a terminé l'événement?

Question

Lorsqu'un utilisateur clique sur un bouton, j'utilise le ThreadPool.QueueUserWorkItem pour générer un thread qui lance un long processus en cours. Je voudrais rendre un bouton visible lorsque le fil est terminé afin que l'utilisateur puisse cliquer dessus.

Y at-il un événement achevé en ThreadPool

Que suis-je en train de faire?

Une des pages possède un bouton lorsque vous cliquez sur se connecte à un WS et lance un long processus qui crée un fichier. Pendant le temps de traitement, je voudrais montrer une barre de progression à l'utilisateur. Une fois le traitement terminé, je voudrais fournir un lien vers le fichier qui a été créé. De nombreux utilisateurs vont cliquer sur le bouton en même temps que cela crée des fichiers différents. Je suppose que vous appelez cela une demande unique qui peut être mise en œuvre en utilisant l'approche Async?

Qs rapide sur les pages Async:

1. Le lien MSDN a le code suivant:

   AddOnPreRenderCompleteAsync ( nouvelle BeginEventHandler (MyBeginMethod), nouvelle EndEventHandler (MyEndMethod) );

Il semble que le MyBeginMethod est Démarré le chargement de la page, sera le même travail d'extrait de code pour moi si je veux lancer le processus async sur un bouton clic?

1. Puis-je accéder aux commandes de l'interface utilisateur dans MyBeginMethod et MyEndMethod méthodes (pour que je puisse faire un bouton de fichier de téléchargement visible sur l'achèvement du processus? Ou est-ce un autre thread propriétaire de ces contrôles?

Answer 1

Non.

vous devez stocker le fait que vous avez terminé quelque part disponible à vos pages ASP.NET et la méthode de faire votre travail, comme le HttpCache.

Si cela est passe aveci n une seule requête, sauter le pool de threads et de vérifier asynchronous pages.

---

Tout d'abord, si le fichier est créé par l'utilisateur, le résultat de la longue action en marche doit être stocké dans la session, pas le cache. Le cache est partagé entre les utilisateurs et la session est par utilisateur. La tâche longue peut créer le fichier, puis stocker le chemin d'accès au fichier dans la session pour cet utilisateur. Chaque fois que l'utilisateur envoie une autre requête pour le fichier, la session est vérifiée pour ce fichier.

Il y a quelques options pour l'interface utilisateur pendant ce temps. L'un est par des publications au serveur, l'autre est des appels ajax.

Ajax n'est peut-être pas le plus simple, même s'il y a beaucoup de frameworks (comme jQuery) et beaucoup d'informations sur la façon de faire une publication asynchrone. Si le processus est très long, les utilisateurs peuvent parcourir, etc, rendant votre tâche plus difficile à mettre en œuvre.

Une autre option consiste à faire votre demande pour le fichier, puis de rediriger vers une page d'attente. Cette page d'attente possède un script qui s'actualise automatiquement toutes les X secondes. Il affiche à l'utilisateur une notification telle que "Veuillez patienter, créer votre fichier". Chaque fois que cette page publie sur le serveur, l'existence du fichier est vérifiée. Si ce n'est pas encore prêt, vous revenez à la page d'attente. Finalement, le fichier devient prêt et vous pouvez rediriger l'utilisateur vers une autre page où le fichier est téléchargé/affiché/peu importe.

La deuxième option est probablement plus facile et plus simple à implémenter. Voici le pseudocode:

1. utilisateur clique sur un lien pour obtenir le fichier
2. Sur postback, serveur redirige vers la page de maintien
3. navigateur de l'utilisateur est redirigé vers la page de maintien
4. demande est traitée par la tenue page. La session est vérifiée pour le fichier.
   1. Si la session signale que le fichier n'a pas été créé et n'est pas créé, le processus de création de fichier est démarré. La page d'attente est renvoyée à l'utilisateur.
   2. Si la session indique que le fichier est en cours de création, la page d'attente est renvoyée à l'utilisateur.
   3. Si les rapports de session le fichier est fait, l'utilisateur est redirigé vers la page de téléchargement
5. La page de maintien a une méthode javascript qui fonctionne sur la charge qui recharge la page toutes les X secondes.

Answer 2

Non, il n'y a pas d'événement terminé dans ThreadPool, ni de moyen simple pour Join().

C'est l'un des problèmes que la classe Task résout dans .NET4. Les tâches ont une méthode Wait().

En attendant, suivez les recommandations de la réponse de Will. ASP.NET asynchrone est facile de se tromper.