Today, Asaph Zemach wrote forth saying... > Hi, > > I've been looking over the gmond sources, and I was wondering > why you saw the need to create the three threads: > proc_stat_thr > proc_loadavg_thr > proc_meminfo_thr > Was there some problem in having the monitor thread perform > these actions? > > I couldn't find an answer in the documentation. Sorry if > I missed it.
Asaph- Ganglia is built to be easily portable to other architectures. If I were to lock it into being simply a Linux tool, then having the proc_stat_thr/proc_loadavg_thr/proc_meminfo_thr threads would not be necessary as I could merge them into the monitor thread. However I wanted the monitor thread to work at a more abstract machine-independent level. The monitor thread shouldn't care about the specifics of how the metrics are collected.. it is only responsible to keeping track of value and time thresholds and making sure new data gets multicast. When I was building the machine-specific file for Linux, I spun off the proc_stat_thr, proc_loadavg_thr, and proc_meminfo_thr to reduce the number of times that the /proc/stat, /proc/loadavg and /proc/meminfo files where opened. Many of the metric functions in read the same file and didn't want each one opening and closing the same file. For example, load_one load_five, load_fifteen, proc_total and proc_run all come from the /proc/loadavg file. To prevent those functions from opening/closing the /proc/loadavg file each time they were called.. they read the file from memory which is updated by the proc_loadavg_thr as necessary. I hope this makes sense. If not, feel free to email back. -matt
