2010-07-01 9 views
5

En expérimentant l'API C de Python (python.org), je me suis demandé comment générer correctement des threads via le package threading de Python lorsque Python lui-même est intégré dans un programme C. Les fonctions PyEval_EvalCode et kin semblent mettre fin aux threads qu'il "possède" dès que la fonction C a fini d'évaluer un bloc de code Python. En gros, exécutant ce qui suit Python de C ...Threads Python en Python embarqué: Comment?

import threading, time 

class MyThread(threading.Thread): 
    def __init__(self, num): 
     self.num = num 
     threading.Thread.__init__(self) 
    def run(self): 
     print "magic num = %d" % self.num 

for x in xrange(1000): 
    MyThread(x).start() 

... arrêtera entièrement dès que la boucle se termine pour le contrôle et est de retour renvoyé hors de la PyEval_EvalCode (ou telle) fonction C. Nous pouvons observer que cela produit une sortie tronquée.

J'émis l'hypothèse ce comportement après avoir utilisé la tactique suivante: Nous pouvons dicter lorsque le contrôle est retourné, et donc à un degré de la sortie, en dormant après la ponte du tas de fils:

for x in xrange(100): 
    MyThread(x).start() 

# Don't leave just yet; let threads run for a bit 
time.sleep(5) # Adjust to taste 

Je soupçonne une possible L'approche consiste à créer un nouveau thread système dédié à l'intégration et à l'exécution de Python. Après avoir engendré des threads Python, le code Python dormait sur un sémaphore ou quelque chose jusqu'à ce qu'on lui dise de s'arrêter. La question serait alors comment le fil peut-il être signalé pour un arrêt ordonné? De même, le bloc "main" peut simplement rejoindre() sur tous les threads; les fils devront alors être signalé de C.

Solutions grandement apprécié ..

Répondre

1

Avez-vous inclus la bibliothèque pthread? Python retombera sur les threads fictifs s'il détecte que les vrais threads ne sont pas disponibles

+0

L'exécutable est lié dynamiquement à libpthread. –