23.10.2013 11:43, Rainer Gerhards:
Secondly, we should switch from the name "global variables". This name
implies very much to everyone who has done at least a little bit of
programming. Most of these implicatons are not true in our context. So I
suggest we call it "state variables" -- or any better name. For now, I will
use "state variables".
This is fine.
Then, in order to find a solution, we need to have some correctness
criterion. As such, I need to write up the restrictions that apply to state
variables. This needs to be thought out, and I can't do it immediately. One
thing I already know, and it is the most important restriction:
State variables cannot be modified more than once when processing a
specific *message*. This means multiple statements with modifications are
permitted, but only one of them can be executed during ruleset evaluation.
An example (pseudo-code):
if $msg contains "tag1" then
set $/glob = "1";
if $msg contains "tag2" then
set $/glob = "2";
This code will execute correctly if msg contains either "tag1", "trag2" or
none of them, but will trigger an runtime-error if msg contains both "tag1"
and "tag2" (as it violates the constraint).
This restriction does not seem useful to me. You can set a "state
variable" multiple times, it will not harm anything.
What makes them different from local variables? State variables can
change unexpectedly between reads. And they will, obviously, not only
because of non-locking nature, but also because of batch execution. So,
to stay away from this property, we could access any variable just once.
These are cases where behaviour will be sane:
1. Just one read.
The value can be saved to a local variable or used in IF statement, it
is OK. If reading twice, chances are to get different and weird results.
2. As many as you want writes could be possible, too. If you do not read
it, you will not be confused.
3. One atomic read and update (as in increment).
Non-atomic read-modify-update is not sane, and it is where your proposed
restriction fails obviously. Think about counters:
set $.local = $/glob + 1;
set $/glob = $.local;
Note: even if the strong restriction was set, user could still shoot
himself in the foot using more than one state variable and conditional
statements. But it is unlikely, I hope.
P.S.
There may be some usecases which will not be covered:
if $/glob = "waiting" and $msg contains "tag" then {
set $/glob = "got it";
action()
}
It will require some additional function:
if $msg contains "tag" then
if atomic_conditional_update($/glob, "waiting", "got it") then
action()
--
Pavel Levshin
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
