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.
Besides that you think it is not useful, do you think it hurts some use
case? Could you accept this restriction?
Rainer
> 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://lists.adiscon.net/mailman/listinfo/rsyslog>
> http://www.rsyslog.com/**professional-services/<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.
>
_______________________________________________
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.
