qu'est-ce que l'utilisation de join() en python threading

J'étudiais le python threading et est venu à travers join().

L'auteur dit que si le thread est en mode démon puis-je utiliser join() de sorte que le fil peut finir lui-même avant les principaux thread se termine.

mais j'ai aussi vu à l'aide de t.join() même si t n'était pas daemon

exemple de code est ce

import threading
import time
import logging

logging.basicConfig(level=logging.DEBUG,
                    format='(%(threadName)-10s) %(message)s',
                    )

def daemon():
    logging.debug('Starting')
    time.sleep(2)
    logging.debug('Exiting')

d = threading.Thread(name='daemon', target=daemon)
d.setDaemon(True)

def non_daemon():
    logging.debug('Starting')
    logging.debug('Exiting')

t = threading.Thread(name='non-daemon', target=non_daemon)

d.start()
t.start()

d.join()
t.join()

je ne sais pas qu'est-ce que l'utilisation de t.join() comme il n'est pas le démon et je ne vois pas de changement, même si je le supprime

  • +1 pour le titre. "Rejoindre" semble être spécialement conçu pour encourager de mauvaises performances (par la création sans cesse/fin/à la destruction de threads), GUI de blocage, (en attente dans le cas des gestionnaires) et de l'application de l'arrêt des échecs, (en attente de secours threads terminer). Remarque - pas seulement en Python, c'est une croix de langue anti-modèle.
InformationsquelleAutor user192362127 | 2013-02-26
  1. 218

    Un peu maladroit ascii-art à démontrer le mécanisme:
    Le join() est sans doute appelé par le thread. Elle pourrait également être appelée par un autre thread, mais serait inutilement compliquer le schéma.

    join-l'appel doit être placé dans la voie de la main-thread, mais pour exprimer thread-relation et de le garder aussi simple que possible, j'ai choisi de le placer dans l'enfant-fil à la place.

    without join:
+---+---+------------------                     main-thread
    |   |
    |   +...........                            child-thread(short)
    +..................................         child-thread(long)

with join
+---+---+------------------***********+###      main-thread
    |   |                             |
    |   +...........join()            |         child-thread(short)
    +......................join()......         child-thread(long)

with join and daemon thread
+-+--+---+------------------***********+###     parent-thread
  |  |   |                             |
  |  |   +...........join()            |        child-thread(short)
  |  +......................join()......        child-thread(long)
  +,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,     child-thread(long + daemonized)

'-' main-thread/parent-thread/main-program execution
'.' child-thread execution
'#' optional parent-thread execution after join()-blocked parent-thread could 
    continue
'*' main-thread 'sleeping' in join-method, waiting for child-thread to finish
',' daemonized thread - 'ignores' lifetime of other threads;
    terminates when main-programs exits; is normally meant for 
    join-independent tasks

    Donc la raison pour laquelle vous ne voyez pas toutes les modifications est parce que votre main-thread ne fait rien après votre join.
    On pourrait dire join est (seulement) pertinentes pour l'exécution des flux de main-thread.

    Si, par exemple, vous voulez simultanément télécharger un tas de pages à les concaténer dans une page unique, vous pouvez commencer à les téléchargements simultanés à l'aide de threads, mais il faut attendre jusqu'à la dernière page/thread est terminé avant de commencer l'assemblage d'une seule page de beaucoup de. C'est lorsque vous utilisez join().

    • S'il vous plaît confirmer automatiquement un thread peut être rejoint() sans bloquer l'exécution du programme?
    • Oui, en utilisant le timeout argument comme: demon_thread.join(0.0), join() est par défaut, le verrouillage, sans égard à la automatiquement l'attribut. Mais en rejoignant un diabolisé fil s'ouvre le plus probable d'un ensemble de ennuis! Je suis en train d'envisager de retirer la join() appel dans mon petit schéma pour le démon-fil...
    • Donc, si nous avons mis sur daemon=True n'avons-nous pas besoin de l' join() si nous avons besoin de la join() à la fin du code?
    • Oui. Si non, alors le fil(=programme) disparaîtraient, si seulement le démon-fil est à gauche. Mais la nature d'un (python) fil de démon, c'est que le thread principal ne se soucie pas si cette tâche en arrière-plan est toujours en cours d'exécution. Je vais réfléchir à la façon de développer dans ma réponse, pour effacer cette question. Merci pour votre commentaire!
    InformationsquelleAutor Don Question
  2. 55

    Directement à partir de la docs

    join([timeout])
    Attendre jusqu'à ce que le thread se termine. Ce qui bloque le thread appelant jusqu'à ce que le thread dont la méthode join() est appelée termine – soit normalement ou par le biais d'une exception non gérée ou jusqu'à ce que l'option délai d'attente se produit.

    Cela signifie que le thread principal, qui engendre le t et d, attend t pour finir jusqu'à la fin.

    Selon la logique de votre programme emploie, vous voudrez peut-être attendre jusqu'à ce qu'un thread se termine avant votre thread principal continue.

    Également de la documentation:

    Un thread peut être marqué comme un “fil de démon”. La signification de ce drapeau, c'est que l'ensemble du programme en Python ferme lorsque seuls les fils de démon sont à gauche.

    Un exemple simple, supposons que nous avons ceci:

    def non_daemon():
    time.sleep(5)
    print 'Test non-daemon'

t = threading.Thread(name='non-daemon', target=non_daemon)

t.start()

    Qui se termine par:

    print 'Test one'
t.join()
print 'Test two'

    Ce sera de sortie:

    Test one
Test non-daemon
Test two

    Ici, le maître fil explicitement attend le t fil à la finition jusqu'à ce qu'il appelle print la deuxième fois.

    Sinon, si nous avons eu cette:

    print 'Test one'
print 'Test two'
t.join()

    Nous allons obtenir ce résultat:

    Test one
Test two
Test non-daemon

    Ici, nous faisons de notre travail dans le thread principal et puis nous attendons le t fil à la fin. Dans ce cas, on pourrait même supprimer l'explicite rejoindre t.join() et le programme implicitement attendre t à la fin.

    • Pouvez-vous faire quelques chnage de mon code afin que je puisse voir la différence de t.join(). en ajoutant soome sommeil ou quelque chose d'autre. au moment où je peux voir tout chnage dans le programme même si je l'utilise ou pas. mais pour damemon je peux voir à sa sortie si j'utilise d.join() qui je ne vois pas quand je ne l'utilise pas d.join()
    • Jetez un oeil à la mise à jour de réponse.
    InformationsquelleAutor dmg
  3. 28

    Merci pour ce thread -- il m'a beaucoup aidé aussi.

    J'ai appris quelque chose .join() aujourd'hui.

    Ces threads s'exécutent en parallèle:

    d.start()
t.start()
d.join()
t.join()

    et ces exécutées de manière séquentielle (pas ce que je voulais):

    d.start()
d.join()
t.start()
t.join()

    En particulier, j'ai essayé de intelligent et bien rangé:

    class Kiki(threading.Thread):
    def __init__(self, time):
        super(Kiki, self).__init__()
        self.time = time
        self.start()
        self.join()

    Cela fonctionne! Mais il s'exécute de manière séquentielle. Je peux mettre de l'auto.start() dans __ init __, mais pas de soi.join(). Ce qui doit être fait après chaque thread a été commencé.

    join() est ce qui provoque le thread principal à attendre que votre fil à la fin. Sinon, le thread s'exécute de lui-même.

    Donc une façon de penser join() comme une "prise" sur le thread principal -- il sorte de de-threads votre fil et exécute séquentiellement dans le thread principal, avant que le thread principal peut continuer. Il assure que votre fil est terminée avant que le thread principal se déplace vers l'avant. Notez que cela signifie que c'est ok si votre fil est déjà fini avant d'appeler le join() -- le thread principal est simplement libéré immédiatement lorsque join() est appelée.

    En fait, tout à l'heure me semble que le thread principal attend à d.join() jusqu'à ce que le thread d finitions avant de passer à t.join().

    En fait, pour être très clair, considérer ce code:

    import threading
import time

class Kiki(threading.Thread):
    def __init__(self, time):
        super(Kiki, self).__init__()
        self.time = time
        self.start()

    def run(self):
        print self.time, " seconds start!"
        for i in range(0,self.time):
            time.sleep(1)
            print "1 sec of ", self.time
        print self.time, " seconds finished!"


t1 = Kiki(3)
t2 = Kiki(2)
t3 = Kiki(1)
t1.join()
print "t1.join() finished"
t2.join()
print "t2.join() finished"
t3.join()
print "t3.join() finished"

    Il produit de cette sortie (note comment imprimer les relevés sont enfilés les uns dans les autres.)

    $ python test_thread.py
32   seconds start! seconds start!1

 seconds start!
1 sec of  1
 1 sec of 1  seconds finished!
 21 sec of
3
1 sec of  3
1 sec of  2
2  seconds finished!
1 sec of  3
3  seconds finished!
t1.join() finished
t2.join() finished
t3.join() finished
$

    Le t1.join() est maintenant en place le thread principal. Les trois fils se terminer avant que le t1.join() se termine et le thread principal se déplace à l'exécution de l'imprimer, puis t2.join (), puis les imprimer ensuite t3.join (), puis imprimer.

    Corrections de bienvenue. Je suis également nouveau sur le filetage.

    (Note: dans le cas où vous êtes intéressé, je suis à l'écriture de code pour un DrinkBot, et j'ai besoin de thread pour exécuter l'ingrédient pompes simultanément plutôt que de façon séquentielle -- moins de temps à attendre pour chaque boisson.)

    • Hey, je suis aussi nouvelle pour python threading et confus sur le thread principal, Est le premier thread thread principal, Si non, pouvez-vous me guider?
    • Le thread principal est le programme lui-même. Chacun des fils sont fourche à partir de là. Ils sont alors rejoint -- parce qu'à la commande join(), le programme attend que le thread est terminé avant de continuer à exécuter.
    InformationsquelleAutor Kiki Jewell
  4. 12

    La méthode join()

    bloque le thread appelant jusqu'à ce que le thread dont la méthode join() est appelée est résilié.

    Source : http://docs.python.org/2/library/threading.html

    • alors, quelle est l'utilisation de la rejoindre? voir OP question, ne pas paraphraser les docs
    • j'ai même essayé d'ajouter le sommeil.minuterie(20) non fil de démon sans l'aide de t.join() et le programme attend encore pour avant la fin de contrat. je ne vois pas de toute utilisation de t.join() ici dans mon code
    • voir ma réponse, pour plus d'explications. concernant votre sommeil.minuterie de non-démon -> un démon-fil est découplée de la durée de vie de c'est parent fil et de sorte que le parent/de frère, de fils ne sera pas affectée par le temps de vie de l'diabolisé fil et vice versa.
    • Le "rejoindre" et de "bloquer" la terminologie est déroutante. "Bloquées" suggère que le processus appelant est "bloqué" de faire n'importe quel nombre de choses qu'il reste à faire, alors qu'en fait c'est juste bloqué par la fin (retour à l'OS), pas plus. De même, il n'est pas si évident qu'il y a un thread principal de l'appel d'une enfant thread pour "rejoindre" il (c'est à dire mettre fin). Donc, Ne Q, merci pour l'explication.
    InformationsquelleAutor Ketouem
  5. 1

    Lors de la prise de join(t) fonction pour les non-fil de démon et le démon thread, le thread principal (ou principal) doit attendre t secondes, alors vous pouvez aller plus loin pour travailler sur son propre processus. Au cours de la t secondes de temps d'attente, les deux enfants threads doivent faire ce qu'ils peuvent faire, comme l'impression du texte. Après la t secondes, si la non-démon thread n'a pas encore fini son travail, et il peut encore terminer après la fin du processus de son travail, mais pour le fil de démon, il a raté de peu sa fenêtre d'opportunité. Cependant, il finira par mourir après le programme python sorties. Veuillez me corriger si il ya quelque chose de mal.

    InformationsquelleAutor user1342336
  6. 1

    En python 3.x join() est utilisé pour joindre un thread avec le thread principal c'est à dire quand join() est utilisé pour un particulier thread le thread principal va s'arrêter jusqu'à ce que l'exécution de la rejoint le thread est terminé.

    #1 - Without Join():
import threading
import time
def loiter():
    print('You are loitering!')
    time.sleep(5)
    print('You are not loitering anymore!')

t1 = threading.Thread(target = loiter)
t1.start()
print('Hey, I do not want to loiter!')
'''
Output without join()--> 
You are loitering!
Hey, I do not want to loiter!
You are not loitering anymore! #After 5 seconds --> This statement will be printed

'''
#2 - With Join():
import threading
import time
def loiter():
    print('You are loitering!')
    time.sleep(5)
    print('You are not loitering anymore!')

t1 = threading.Thread(target = loiter)
t1.start()
t1.join()
print('Hey, I do not want to loiter!')

'''
Output with join() -->
You are loitering!
You are not loitering anymore! #After 5 seconds --> This statement will be printed
Hey, I do not want to loiter! 

'''
    InformationsquelleAutor Shishir Nanoty
  7. 1

    Simple À Comprendre,

    avec join - interprète attendre jusqu'à ce que votre processus terminé ou résilié

    >>> from threading import Thread
>>> import time
>>> def sam():
...   print 'started'
...   time.sleep(10)
...   print 'waiting for 10sec'
... 
>>> t = Thread(target=sam)
>>> t.start()
started

>>> t.join() # with join interpreter will wait until your process get completed or terminated
done?   # this line printed after thread execution stopped i.e after 10sec
waiting for 10sec
>>> done?

    sans jointure - interprète l'habitude d'attendre jusqu'à ce que le processus d'obtenir résilié, 

    >>> t = Thread(target=sam)
>>> t.start()
started
>>> print 'yes done' #without join interpreter wont wait until process get terminated
yes done
>>> waiting for 10sec
    InformationsquelleAutor Silent Spectator
  8. 0

    Cet exemple démontrer la .join() action:

    import threading
import time

def threaded_worker():
    for r in range(10):
        print('Other: ', r)
        time.sleep(2)

thread_ = threading.Timer(1, threaded_worker)
thread_.daemon = True  # If the main thread kills, this thread will be killed too. 
thread_.start()

flag = True

for i in range(10):
    print('Main: ', i)
    time.sleep(2)
    if flag and i > 4:
        print(
            '''
            Threaded_worker() joined to the main thread. 
            Now we have a sequential behavior instead of concurrency.
            ''')
        thread_.join()
        flag = False

    Out:

    Main:  0
Other:  0
Main:  1
Other:  1
Main:  2
Other:  2
Main:  3
Other:  3
Main:  4
Other:  4
Main:  5
Other:  5

            Threaded_worker() joined to the main thread. 
            Now we have a sequential behavior instead of concurrency.

Other:  6
Other:  7
Other:  8
Other:  9
Main:  6
Main:  7
Main:  8
Main:  9
    InformationsquelleAutor Benyamin Jafari
  9. -2

    "Quelle est l'utilité de l'aide de join()?" dites-vous. Vraiment, c'est la même réponse que "l'utilisation de la fermeture des fichiers, depuis le python et le système d'exploitation va se fermer mon fichier pour moi, lorsque mon programme s'arrête?".

    C'est simplement une question de bonne programmation. Vous devriez vous joindre() de votre fils au point dans le code que le thread doit pas être en cours d'exécution plus, soit parce que vous positivement assurer le thread n'est pas en cours d'exécution pour interférer avec votre propre code, ou que vous souhaitez à se comporter correctement dans un système plus vaste.

    Vous pourriez dire: "je ne veux pas que mon code pour le retard de donner une réponse" juste parce que le temps supplémentaire que le join() pourrait exiger. Cela peut être parfaitement valable dans certains scénarios, mais vous devez maintenant prendre en compte le fait que votre code est "laisser des trucs autour de python, et l'OS à nettoyer". Si vous faites cela pour des raisons de performances, je vous encourage fortement à document de comportement. Cela est particulièrement vrai si vous êtes la construction d'une bibliothèque/paquet que les autres sont censés utiliser.

    Il n'y a pas de raison de ne pas rejoindre(), autres que des raisons de performances, et je dirais que votre code n'a pas besoin d'effectuer que bien.

    • Ce que vous dites sur le nettoyage des threads n'est pas vrai. Regardez le code source de filetage.Fil de discussion.join(). Tous cette fonction n'est à attendre sur un verrou, puis retour. Rien n'est réellement nettoyé.
    • Le fil lui-même peut être tenue de ressources, dans ce cas, l'interprète et l'OS sera en effet nécessaire de nettoyer les "trucs".
    • Encore une fois, regardez le code source de filetage.Fil de discussion.join(). Il n'y a rien là qui déclenche la collecte de ressources.
    • Ce n'est pas nécessairement (et comme vous le dites, pas du tout) le module threading qui conserve les ressources, mais le fil lui-même. À l'aide de join() signifie que vous êtes en attente pour le fil d'arrivée à faire ce qu'il voulait faire, ce qui pourrait inclure d'allouer et de libérer des ressources.
    • Si vous attendez ou pas n'a pas d'incidence sur le moment où les ressources détenues par le thread sont libérés. Je ne suis pas sûr de savoir pourquoi vous êtes liant avec l'appel de join().
    InformationsquelleAutor Chris Cogdon