One of the threads is the "main thread" that controls the 10 worker-threads. This is a screenshot of what that looks like: (Customers don't want to kill threads, but I need to for testing purposes to know if Backblaze can recover.) Since at the time bztransmit was using shared libraries, each binary was only 300 KBytes, so this "wasted" only 2.7 Mbytes of disk, and nobody noticed. My "hack" was to make 10 copies of the bztransmit.exe executables on disk with the installer, named bztrans_thread01.exe, bztrans_thread02.exe, etc and then when I wanted to launch thread "7" I would execute bztrans_thread07.exe and it would clearly be seen in "Task Manager" without external tools, and I could even kill an individual thread that way.
At the time (circa 2005 maybe?) you could download a set of tools named "System Internals" and then you could see the separate threads running, but you couldn't tell which thread was "hung" if there was an issue. The Windows "Task Manager" wouldn't show the threads, it would just list one executable name. Ok, so something frustrated me about working on threads at a previous company. Customer network upload speeds were getting faster, but they weren't as fast as today, so we started with a maximum of 10 threads. I added threads to the Backblaze client in 2015. I had to write extra code in the installer to make the extra copies that all have different names. The Windows installer actually only contains 1 copy of a 32 bit version of bztransmit.exe, and 1 copy of the 64 bit version. I get some flack for this, but it was a conscious decision and well intentioned. Why are there 20+ copies each of bztransmit.exe and bztransmit64.exe on disk? Disclaimer: I work at Backblaze and wrote extra code to put 20 copies of bztransmit.exe on your drive.
0 kommentar(er)
