This issue has been migrated from Redmine: https://dev.icinga.com/issues/2242
Created by mfriedrich on 2012-01-04 10:04:10 +00:00
Status: Closed (closed on 2012-05-05 12:05:53 +00:00)
Target Version: (none)
Last Update: 2012-05-05 12:05:53 +00:00 (in Redmine)
protecting the check result lists in memory with a mutex ourselves we can make sure that modules could use the same mutex to gain exclusive access to that list.
at least DNX and mod_gearman use a special merge on that list before the reaping event happens, but this should be controlled by the core itsself.
especially when icinga-mq allows to pass check results via api, this will become mandatory to protect the core internal check result list.
Updated by mfriedrich on 2012-01-27 20:30:22 +00:00
Updated by mfriedrich on 2012-02-18 12:25:25 +00:00
found this elsewhere as well. seems to also affect the inner parts of the core itsself, not locking shared ressources properly.
add_check_result_to_list() and read_check_result() need mutex locking to prevent corruption of check_result_list.
Both the main and worker threads make calls to add_check_result_to_list but only the main thread calls read_check_result. However, both should acquire mutex locks for their modifications to the shared resource: check_result_list.
Updated by mfriedrich on 2012-02-18 14:33:49 +00:00
must be sort of an external addon in the above bug report, as this does not happen by default.
either way, such a lock would be nice to have when we implement -mq.
Updated by mfriedrich on 2012-03-04 12:27:31 +00:00
Updated by mfriedrich on 2012-05-05 12:05:53 +00:00
no, locks which are not used, are worthless.