On Wed, 23 Oct 2013, Rainer Gerhards wrote:
On Wed, Oct 23, 2013 at 10:40 AM, Pavel Levshin <[email protected]>wrote:
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.
This restriction is useful if it avoids the really bad bahavior of different
statements interacting in unexpected ways due to the SIMD engine.
Besides that you think it is not useful, do you think it hurts some use
case? Could you accept this restriction?
I would have it create a loud warning, not a runtime error (runtime error
implies stopping, at least to me)
As Pavel describes, people 'fixing' this error can still get themselves in
trouble by way of temporary local variables, so it doesn't stop all problems,
but I think it's acceptable as a strong warning (really scary warning message
:-)
David Lang
_______________________________________________
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.
