J'essaie de créer une application Web simple à l'aide de Python sur GAE. L'application a besoin de reproduire des fils par demande reçus. Pour cela, j'utilise la bibliothèque de threading de Python. J'attendais tous les fils, puis attends sur eux.
application: myapp version: 1 runtime: python27 api_version: 1 threadsafe: true handlers: - url: /favicon\.ico static_files: favicon.ico upload: favicon\.ico - url: /stylesheet static_dir: stylesheet - url: /javascript static_dir: javascript - url: /pages static_dir: pages - url: .* script: main.app
3 Réponses :
Les notes de multithreading pour GAE ne sont que pour la manière dont les demandes sont manipulées - elles ne changent pas fondamentalement comment fonctionnent les threads de Python. Plus précisément, le "détail de mise en œuvre CPPHON" Note dans le le module de filetage Documents s'applique toujours.
Il convient également de mentionner la note dans la section "Sandboxing" des Documents GAE:
Notez que les threads seront joints par le temps d'exécution lorsque la requête se termine, Donc, les threads ne peuvent pas dépasser la fin de la demande.
Merci Nick pour la réponse. Donc, le support multithreading dans GAE implique-t-il que le GAE peut apparaître plusieurs threads pour gérer des demandes en parallèle, mais le code d'application lui-même ne peut-il pas reprocher les fils d'assistance?
@NITESH: L'avant de cette aiguille des mains est capable de frayer plusieurs instances de votre application pour gérer ces demandes, mais les threads que vous créez dans chaque instance sont toujours liés par des règles normales. Vous pouvez bien sûr développer des fils d'assistance, mais ils ne courront pas simultanément à moins qu'ils ne bloquent les E / S.
Dans les fils d'assistance, je fais un appel d'Urllib.urlopen. Cet appel n'est-il pas bloqué?
Ainsi, dans Gae, Urllib n'est pas implémentée de la même manière que dans votre python local: code.google.com/appengine/docs/python/urlfetch/overview.html Si ces appels se comportent de la même manière dans les threads ne sont pas couverts dans la documentation.
Nick, faisant ressortir le "Détail de la mise en œuvre de CPPHon" (c'est-à-dire que le gil) ici n'est pas pertinent car les threads ici sont liés I / OS afin qu'ils ne soient pas limités par le gil - il est libéré dès que des blocs de threads pour i / O (tel qu'un appel d'urlfetch ou une opération de magasin de données). Donc, Nitesh a raison et des fils simultanés faisant des appels RO Urlfetch ou Urlopen faire courir simultanément, même si les documents ne le couvrent pas explicitement.
@Guidovanrossum: Bon à savoir - sauver des preuves documentaires au contraire, il semblait judicieux de supposer que l'on ne pouvait pas s'attendre à une simulation dans l'API Urlfetch .
Si vos threads attendent principalement des opérations de magasin de données, vous pouvez essayer le NDB Module qui fait partie de 1.6.2. La sémantique sera suffisamment proche de ce que vous faites.
IIRC, le drapeau multithreading permet à une instance de serveur de servir plusieurs demandes sur des threads distincts, mais ne vous permettrai pas de démarrer vous-même des threads. Si vous n'avez pas besoin de les synchroniser avant de retourner, vous pouvez les mettre sur des Tâches < / a> et les déléguer à une ou plusieurs files d'attente de tâches.
En fait, le temps d'exécution PY27 permet de créer des threads. (Mais voir la note ajoutée dans la première réponse ci-dessus - elles seront jointes lorsque la requête se termine.)
Merci pour la correction et pour le conseil beaucoup mieux que le mien.
Il existe une nouvelle fonctionnalité appelée "filets de fond", qui sont comme des fils réguliers, à l'exception des threads de fond ne sont pas implicitement joints à la fin d'une demande: développeurs.google.com/appengine/docs/python/Backends/...
Vérez-vous cela dans le Dev_AppServer ou après avoir téléchargé votre application au service de production? De votre mention de GoogleApplauncher, il semble que vous voyiez peut-être cela dans le dev_appserver; Le dev_appserver n'émule pas le comportement de filetage des serveurs de production et vous seriez surpris de constater qu'il fonctionne simplement bien après avoir déployé votre application. (Sinon, ajoutez un commentaire ici.)
Une autre idée: Si vous attendez surtout l'urlfetch, vous pouvez exécuter de nombreux appels Urlfetch en parallèle en utilisant l'interface ASYNC sur Urlfetch:
http://code.google.com/appengine/docs/python/urlfetch/asynchronousrequests.html < / a>
Cette approche ne nécessite pas de threads. (Il n'est toujours pas corrigé correctement les demandes du dev_appserver; mais cela fait des choses correctement sur les serveurs de production.)
Ouais je vivais le problème sur mon installation locale seulement. Les threads ont couru en parallèle lorsque j'ai téléchargé mon application. Merci pour l'aide.