Ceci est en référence à la question Stackoverflow Question Gestion de plusieurs connexions NsurLConnection asynchrones
J'ai plusieurs demandes HTTP asynchrones étant faites en même temps. Tous ceux-ci utilisent les mêmes fonctions de délégués NsurlConnection. (L'objet reçuData est différent pour chaque connexion spécifiée dans l'autre question ci-dessus. Dans le délégué, je analysais l'objet reçus et effectuez des opérations supplémentaires sur ces chaînes analysées)
Tout fonctionne bien pour moi jusqu'à présent, mais je ne sais pas si je dois faire quelque chose pour assurer un comportement "multithreadisé" correct.
3 Réponses :
En supposant que vous lancez toutes les connexions (asynchrones) sur un seul thread, les messages délégués seront tous postés dans la boucle d'exécution de ce fil. Par conséquent, le délégué n'a que la possibilité de faire face à un seul message manipulé à la fois; La boucle de course remettra un message à la fois. Cela signifie que, si l'ordre des messages de délégation est inconnu et que le prochain message pourrait provenir de tout objet de connexion, aucune exécution simultanée de vos méthodes de délégation.
Cependant, essayiez-vous d'utiliser le même objet de délégué sur plusieurs threads, plutôt que de simplement utiliser la nature asynchrone de l'API, vous aurait besoin de traiter des méthodes de délégation simultanentes.
Oui, il est possible d'avoir plusieurs connexions. L'objet de notification contient un pointeur sur le interne, je suppose nsurlconnection code> qui a déclenché la notification. nsurlconnection code> écoute sur une prise et fait quelque chose comme ça quand il contient des données prêtes. P> [your_delegate
performSelectorOnMainThread:@selector(connectionCallback:)
withObject:self
waitUntilDone:NO];
J'ai amélioré la bibliothèque de trois20 pour implémenter des connexions asynchrones sur plusieurs threads afin d'aller chercher des données même si l'utilisateur jouait avec l'interface utilisateur. Après de nombreuses heures de poursuite des fuites de mémoire aléatoires qui ont été détectées dans le cadre de la CFNetwork, j'ai enfin causé la question. Je perdais occasionnellement une trace des réponses et des données.
Toute structure de données accessible par plusieurs threads doit être protégée par un verrou approprié. Si vous n'utilisez pas de verrous pour accéder à des structures de données partagées de manière mutuellement exclusive, vous n'êtes pas en sécurité. Voir le " Utilisation de Serrures "Section de Apple's Guide de programmation de threading .
La meilleure solution consiste à sous-classes nsurlconnection et à ajouter des variables d'instance pour stocker ses données de réponse et de réponse associées. Dans chaque méthode de déléguée de connexion, vous apportez ensuite la NsurlConnection à votre sous-classe et accédez à ces variables d'instance. Ceci est garanti d'être mutuellement exclusif car chaque connexion sera baignée par sa propre réponse et ses données. Je recommande fortement d'essayer cela puisqu'il s'agit de la solution la plus propre. Voici le code de ma mise en œuvre:
Merci pour votre suggestion, je crois que c'est le moyen le plus efficace de gérer cela. Je suis assez surpris que, après tant d'années, Apple n'a toujours pas seulement grimpé de nsmutaberdata * à NsurlConnection. Je ne vois pas une raison pour laquelle ils ne devraient pas. C'est une opération assez standard ne diriez-vous pas?