Actions
Optimization #1018
closedclean up counters api
Effort:
Difficulty:
Label:
Description
The counters api is large but has many unused parts. Clean up is needed to better understand the code, to shrink data types and to reduce it's overhead.
Updated by Victor Julien about 11 years ago
- Status changed from Assigned to Closed
Addressed by the following commits.
commit 64f5129f124b8077c8417326feb9b650849d0a74 Author: Victor Julien <victor@inliniac.net> Date: Tue Oct 29 09:04:07 2013 +0100 Counters: remove unused tm_name comparison loops commit 76c305c1282b481babb85815469be47652df855d Author: Victor Julien <victor@inliniac.net> Date: Tue Oct 29 08:29:11 2013 +0100 Counters: fix unix socket commit 25aeeebdf7d0ab2b4753189f3fca1f41078d26d8 Author: Victor Julien <victor@inliniac.net> Date: Tue Oct 29 08:19:16 2013 +0100 Counters: merge SCPerfCounterName into SCPerfCounter as there was a 1 on 1 mapping commit 3445d17ae5b5903b89eec5a66559e31fec2871fb Author: Victor Julien <victor@inliniac.net> Date: Tue Oct 29 08:00:06 2013 +0100 Counters: remove SCPerfCounterValue struct as we no longer support multiple data types commit 677cd03e5291016bcb0231cb9fd9f4594c53b2d2 Author: Victor Julien <victor@inliniac.net> Date: Tue Oct 29 00:34:13 2013 +0100 Counters: more unused code removal commit 8d4a61a789a910f044fc04f7c9909905121a5db5 Author: Victor Julien <victor@inliniac.net> Date: Tue Oct 29 00:10:38 2013 +0100 Counters: remove unused code commit 698ff4e4aa3f781a4d792705946ec81d99069fb1 Author: Victor Julien <victor@inliniac.net> Date: Mon Oct 28 19:00:06 2013 +0100 Counters: remove all unused parts of the API
Updated by Victor Julien about 11 years ago
- Status changed from Closed to Assigned
Seeing a segv that seems to be related to my changes, investigating.
Updated by Victor Julien about 11 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
Fixed by:
commit 7ebd1e6433bfdf7c66d70156f82ad4940a186c70 Author: Victor Julien <victor@inliniac.net> Date: Thu Oct 31 11:39:59 2013 +0100 Counters: fix delayed-detect counter registration Make sure we register the detect.alerts counter before packet runtime starts even in delayed detect mode. The registration of new counters at packet runtime is not supported by the counters api and might lead to crashes as there is no proper locking to allow for this operation. This changes how delayed detect works a bit. Now we call the ThreadInit callback twice. The first call will only register the counter. The 2nd call will do all the other setup. This way the counter is registered before the counters api starts operating in the packet runtime. Fixes the segv reported in ticket #1018.
Actions