On 5. sep. 2005, at 09.53, Martin Pala wrote:
Jan-Henrik Haukeland wrote:
I have only browsed through the patch and it looks fine by me,
although I'm not quite sure what is going on with the
Event.state_map bit-flicking :-)
The state is kept in in the bitmap which workes similar to the
ringbuffer -
Thanks for the explanation
Since you use a long long (could uint64_t be used instead?) does
this mean that there are only room for 64 failed/ passed events?
Right. The bitmap is adaptive - depending on how large the 'long
long' type is on given architecture, then the corresponding cycles
count history are kept.
The parser checks for 'long long' size vs. cycles count in the rule
and reports the corresponding maximal value when the cycles count
is greater then can be described by the 'long long' bitmap.
I didn't see that one. Good solution!
--
Jan-Henrik Haukeland
Mobil +47 97141255
_______________________________________________
monit-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monit-dev
