Autorisation des threads de python après l'appel d'un code d'E/S bloquant dans une extension python générée en utilisant SWIG

Question

J'ai écrit une extension python enveloppant une bibliothèque C++ existante live555 (enveloppe l'interface client RTSP pour être spécifique) dans SWIG. L'extension fonctionne quand elle est utilisée dans un seul thread, mais dès que j'appelle la fonction de boucle d'événements de la bibliothèque, l'interpréteur python ne récupère jamais le contrôle. Donc, si je crée une tâche planifiée en utilisant threading.Timer juste avant d'appeler la boucle d'événement, cette tâche ne sera jamais exécutée une fois que la boucle d'événements commencera. Pour résoudre ce problème, j'ai ajouté manuellement les macros Py_BEGIN_ALLOW_THREADS et Py_END_ALLOW_THREADS dans le fichier cxx wrapper généré automatiquement par SWIG autour de chaque appel de fonction doEventLoop(). Mais maintenant, je veux faire la même chose (c'est-à-dire autoriser les threads) quand SWIG génère le code lui-même et ne pas changer de code manuellement. Quelqu'un at-il fait quelque chose de similaire dans SWIG?

P.S. - Je voudrais également envisager de passer à un autre cadre (comme SIP) pour que cela fonctionne. J'ai choisi SWIG sur n'importe quelle autre technologie parce que l'écriture de l'interface SWIG était vraiment très simple et que je devais simplement inclure les fichiers d'en-tête existants. SWIG vous donne beaucoup de crochets pour aider à ce que cela se produise.

Answer 1

Si une solution grossière est suffisante pour vos besoins, une chose que je l'ai fait dans le passé est mis quelque chose comme ça dans mon dossier .swig:

%exception { 
    Py_BEGIN_ALLOW_THREADS 
    $action 
    Py_END_ALLOW_THREADS 
} 

Ce (ab) utilise l'installation SWIG pour décorer les appels de fonction C avec une sorte de logique de gestion des erreurs afin de décorer ces appels avec un déverrouillage/verrouillage GIL. Voir Exception handling with %exception dans les documents SWIG pour plus de détails sur ce qui se passe ici.