Thus really makes it clear to me that I should remove global vars. Chances are too high this will cause immense confusion.
Rainer Sent from phone, thus brief. Am 21.10.2013 22:12 schrieb "Pavel Levshin" <[email protected]>: > > 21.10.2013 14:45, Rainer Gerhards: > >> yeah, mmsequence works, and it does so because it kind of atomically >> increments the global count saves this value to the message variable. If I >> had already implemented that (planned) function, you could do the same >> thing in scripting via >> > > set $$!msgctr = atomic_inc($$/zz); and use $$!msgcntr for the rest of the >> checks. >> > > Yes, but this function does not look as a general solution, as it would > be. It is just a sequence generator, and even mmsequence is better for this > purpose. By the way, is it possible to read and set local/global variables > from the module? > > (Also, I could dream of dynamic loadable functions - just like modules, > which can execute in message context.) > > The so-called "SIMD" engine is very counter-intuitive, particulary when > it's syntax replicates conventional shell. (It is not SIMD, in reality, > because it iterates every line instead of executing in parallel.) It is > transparent for local variables and messages, but it is disastrous for > global variables. Everytime anyone will do complex computations with global > variables, he will be surprised with unexpected results. And, for complex I > mean computation which consist of more than one line of script, which is > like anyone does in every scripting language. Worse yet, it will work for > tests under low load, where batch=1, but will fail at production. Those > implications need to be noted in BIG RED LETTERS everywhere to prevent > user's confusion. > > But global variables are still useful for some kind of things. Like, say, > changing rsyslog's behaviour without reload. And, to some extent, for rough > counters; but I honestly cannot contrive any valid application for that. > > Consistent look is good, while global variable remains constant. It > becomes worse when a user thinks that similarily looking entities will > behave alike. > > To work around known limitations, I would suggest something like enclosing > group of statements into a block, which is either executed atomically or > supports locking for global variables. Something like this: > > Atomic { > set $/var1 = $/var1 + 1; > if $/var1 > 10000 and $/var2 == "waiting" then { > set $/var2 = "overload"; > } > } > > Or > > Do (lock="$/var1 $/var2") { > set $/var1 = $/var1 + 1; > if $/var1 > 10000 and $/var2 == "waiting" then > set $/var2 = "overload"; > } > > Just thoughts. > > > -- > 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.
