understanding this multithreading demon python code -

understanding this multithreading demon python code -

so beginner in python , working on filesystem event handler. came across watchdog api , there saw multithreading code cannot understand.

here code published on website:

import sys import time import logging watchdog.observers import observer watchdog.events import loggingeventhandler if __name__ == "__main__": logging.basicconfig(level=logging.info, format='%(asctime)s - %(message)s', datefmt='%y-%m-%d %h:%m:%s') path = sys.argv[1] if len(sys.argv) > 1 else '.' event_handler = loggingeventhandler() observer = observer() observer.schedule(event_handler, path, recursive=true) observer.start() try: while true: time.sleep(1) except keyboardinterrupt: observer.stop() observer.join()

this code runs infinite loop , listens on folder , logs sees console. uncertainty way on bottom of code.

so start observer. inquire go on infinite loop until keypress done. assuming somewhere in "observer.start()" code, setting daemon=true. upon keypress, programme runs out of loop , stops observer. in watchdog's api, definition of stop() says stops daemon thread.

1) join(). need join. have stopped daemon thread. isn't join() means wait threads stop , , exit program. can remove join() code. after remove it, programme still works correctly.

2) don't understand need of sleep(1) within while loop. happen if set "pass" statement there. assuming while loop consume more resources??? , reason have set sleep time 1 sec , not 2-3 seconds because in worst case, user might have wait 2-3 seconds programme close. might wrong.

remember daemon running in parent process's, well, process. need maintain parent process live while thread executing, or else killed programme exited (and in not graceful way). join makes sure process stays live until threads exit; because called stop doesn't guarantee thread has completed execution. stop request thread stop, doesn't require block until thread terminates (nor should parent thread can phone call stop on many kid threads 'at once').

this purely reduced cpu consumption. if had pass in there, cpu run while loop fast possible, waisting cycles. sleep phone call voluntarily yields cpu other processes since knows isn't going need respond particular conditions. , correct, it's sleep(1) worst-case response time approximately 1 second.

update:

here illustration of why having join important. next running in thread:

while not self.stop: # self.stop set true when stop() called ... self.results.append(item) # stuff involves appending results list open('~/output.txt', 'w') outfile: outfile.write('\n'.join(str(item) item in item))

when stop called, while loop terminate, , result file open , start writing. if join wasn't called, process terminate before write operation completes, cause corrupted results. join ensures parent thread waits write finish. ensures process waits whole iteration of while-loop finish; without join not miss file write, terminate in middle of while block.

if thread had stop called on didn't lengthy after while terminated, join homecoming instantly , turns nop.

update 2:

with respect sleep call, events (such ctrl+c) can bubble out of sleep phone call on parent process. in particular case, length of sleep doesn't matter much. setting 1 sec convention create clear you're doing 'yield cpu' rather sleeping sleeping.

python-multithreading python-3.4 python-watchdog