Am 05.06.2015 um 01:51 schrieb Paolo Bevilacqua:
> Harald Oehlmann writes:
>> the "global" discussion is a side note and IMHO not the point you are
>> facing. I am guessing.
>> If you start Apache, it creates typically, at least, 4 processes with a
>> tcl interpreter each.
>> So if you do set "::myvar 1" in your rivet script once, you will find
>> [info exists :myvar] true each 4th call or so.
>> To resume, you don't have true globals by principle.
>> If you want to share an information among all interpreters, you
>> typically use a data base or a file or a socket connection, but global
>> variables will not work.
>
> Hi Harold,
> Of course you are correct, I understand that now also thanks to
> Massimo's help.
> However I don't agree that the documentation that I quoted before can be
> considered just a sidenote, I was mislead to believe that persistent,
> global variable were easily possible.The doc is, at the minimum,
> ambiguous:
> "Your application can rely on the fact that certain application data
> will be in the interpreter, but you shouldn't assume the state of a
> transaction spanning several pages can be stored in this way and be
> safely kept available to a specific client"
>
> What is the point of having "data in the interpreter" when there is no
> method to retrieve it safely ?
> I believe that should be changed and the caveat be highlighted to avoid
> pitfalls to beginners..
>
> Thanks, Paolo.
Dear Paolo,
we are sorry for this experience and that you feel mislead.
I am sure we will find a better wording.
The use of this type of persistence is at follows:
- apache starts and ends processes "on demand".
- each time a tcl process is started, one can do initialisation work
once like that:
if {![info exists ::initialized]} {
package require MyAdditionalPackages
set ::dbHandle [opendatabase]
set ::fileHandle [open MyLogFile$PID.txt w]
set ::initialized 1
}
You see the picture ?
(you can do the same thing via "initScripts" but the upper solution
works well to and is ok for short running init).
Happy that you are here,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
