23.10.2013 14:58, Rainer Gerhards:
Let me elaborate a bit more. Obviously, the problems with state variables
occur only when they are update. If they were read-only, no problem would
ever exist. But for some reason it makes very limited sense to have
read-only state ;)
It is not quite correct. Write-only variables also are fine. It is a
combination of read and write what makes the trouble. That is why it
need to be done atomically.
So this would be too hard an restriction.
Thinking along these lines, I wonder if things become easier if we at least
limit the number of updates.
One other restriction in this regard is
A state variable cannot be modified after it has been accessed.
Note that this is a far stricter restriction that "cannot be modified after
it has been modified". It would make it impossible to write my above sample
without the help of a specific atomic function, but it would still permit
set $/z = $/z +1
write $/z
which would not be permitted if we say "cannot be accessed more than once".
If a variable cannot be modified after it has been accessed, then
set $/z = $/z + 1;
is already forbidden. Unless you are not going to account the statement
as atomic, or make a difference between access and storing value in
local context.
Please note that read after modify is also problematic, because it
breaks a very common pattern:
set $/z = $/z + 1; here we read and then write, OK so far
if ($/z % 10 == 0) then oops, it is the read causing
misubderstanding.
--
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.
