python_pinger.git

1) # python_pinger
2) 
3) These are different approaches to how one might implement a daemon to
4) repeatedly ping multiple hosts to see if the network is up.
5) 
6) ## Single Threaded
7) 
8) This is the most naive implementation. For each ping host, the main
9) process thread pings them one at a time, and prints any changes.
10) 

11) ![Single Threaded Pings](http://dlma.com/images/python_pinger/ping_single_threaded.png)
12) 
13) It's so simple that I'm not going to provide a sample source file, but for the others below, I will.

14) 
15) ### Upsides
16) 
17) Really simple code.
18) 
19) ### Downsides
20) 
21) Since the pings are serialized, one long timeout from one host could
22) affect detecting a problem at another host.
23) 
24) ## Long Lived Workers Consuming from Queue
25) 
26) Raymond Hettinger's [PyBay 2018 Keynote](https://pybay.com/site_media/slides/raymond2017-keynote/threading.html)
27) uses the queue module to send data between threads, so I thought I'd make a version of the pinger that did the same.
28) 

29) ![Long Lived Queue Workers](http://dlma.com/images/python_pinger/ping_long_lived_queue_workers.png)

30) 

31) See the source: **[long\_lived\_worker\_queue.py](http://git.dlma.com/python_pinger.git/blob/master/long_lived_worker_queue.py)**

32) 
33) ### Upsides
34) 
35) Multi-threaded ping calls won't block each other.
36) 
37) ### Downsides
38) 

39) The ping tasks read from, and write to a shared dictionary. (Reading and
40) updating the last status.)

41) 
42) ## Short Lived Workers
43) 

44) How about we don't keep the workers around, and only spawn them when

45) there's something to do? That way, we won't waste memory when there's
46) nothing going on.
47) 
48) ![Short Lived Workers](http://dlma.com/images/python_pinger/ping_short_lived_workers.png)

49) 

50) See the source: **[short\_lived\_workers.py](http://git.dlma.com/python_pinger.git/blob/master/short_lived_workers.py)**

51) 
52) ### Upsides
53) 
54) The worker tasks aren't in memory if they're not doing anything. So usually a smaller memory profile.
55) 
56) ### Downsides
57) 
58) The ping tasks still read from, and write to a shared dictionary. (Reading and updating the last status.)
59) 
60) ## Long Lived Looping Workers
61) 

62) I saved the best for last. The only thing the main thread does is bring the
63) workers and the print manager to life. The workers each independently do their own loop:
64) ping, compare, print, and wait.
65) 
66) ![Long Lived Looping Workers](http://dlma.com/images/python_pinger/ping_long_lived_looping_workers.png)

67) 

68) See the source: **[long\_lived\_looping\_workers.py](http://git.dlma.com/python_pinger.git/blob/master/long_lived_looping_workers.py)**

69) 
70) ### Upsides
71) 
72) No more race conditions! The worker threads mind their own business.
73) 
74) ### Downsides
75) 
76) The worker threads remain in memory.
77) 

78) ## Long Lived Looping Locked Workers
79) 
80) That was fun using only the synchronized queue class and no locks. But now that
81) we've got the long lived looping workers that don't need their own queue, let's
82) replace the print manager with a threading lock.
83) 
84) ![Long Lived Looping Locked Workers](http://dlma.com/images/python_pinger/ping_long_lived_looping_locked_workers.png)
85) 
86) See the source: **[long\_lived\_looping\_locked\_workers.py](http://git.dlma.com/python_pinger.git/blob/master/long_lived_looping_locked_workers.py)**
87) 
88) ### Upsides
89) 
90) Got rid of the entire printer thread.
91) 
92) ### Downsides
93) 
94) Uses a lock, which in more complex applications with multiple locks becomes difficult to reason about.
95)