OK, thx everyone for now. Looks like too much dev mind currently floating and we can't discuss restrictions without implementation details. I'll do a follow up post when I am ready to discuss the idea I got. But first I want to finish the name refactoring, then think a bit about use cases and restrictions that would break them and then see if the idea is worth discussing.
As a very rough explanation, I think about a system of shadow variables, where the state variable is cached to a local copy on first access, update, whenever... Automagically, the cached copy will be used from then on. But I am really not yet ready to discuss any details. Rainer On Wed, Oct 23, 2013 at 1:23 PM, Pavel Levshin <[email protected]> wrote: > 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://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.
