Re: Are global variables truly global?
I have some state data that I need to persist between requests. At the moment these are COM objects, but they'll be ported to Perl Classes. It is quite important that only one of these instances exist per web server. These instances are too large to write and read to file on every request. So I have defined the variable as a package level variable. Package level variables are shared upon fork(), in the sense that the memory segment(s) they use is made available to all child processes. BUT the memory itself isn't shared, and any subsequent write to the variable in one of the children will not reflect in the others. So unless your state data is a constant, this is not what you want. -- Tout n'y est pas parfait, mais on y honore certainement les jardiniers Dominique Quatravaux [EMAIL PROTECTED]
RE: Are global variables truly global?
-Original Message-
From: Chui G. Tey [mailto:[EMAIL PROTECTED]]
package Apache::MyPkg;
my $COM_instance;
sub handler {
if (!$COM_instance) {
$COM_instance = Win32::OLE-new(ProgID.Class);
}
}
Will the different child processes created by Apache share the same
variable? Or will each child create an additional instance?
It looks like you're using Win32, so you only get one process anyway - no
children, no forking. All the other suggestions apply if you intend to be
cross platform once you switch from COM to Perl objects though.
Matt.
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
Are global variables truly global?
I have some state data that I need to persist between requests. At the
moment these are COM objects, but they'll be ported to Perl Classes. It
is quite important that only one of these instances exist per web
server. These instances are too large to write and read to file on every
request. So I have defined the variable as a package level variable.
I have been instantiating the variable in my handler() routine if it has
not already been instantiated. ie.
package Apache::MyPkg;
my $COM_instance;
sub handler {
if (!$COM_instance) {
$COM_instance = Win32::OLE-new(ProgID.Class);
}
}
Will the different child processes created by Apache share the same
variable? Or will each child create an additional instance? I'm happy to
lose the data if Apache falls over.
Chui Tey
Software Engineer
Advanced Data Integration
PO Box 660
Spring Hill QLD 4004
AUSTRALIA
Ph:07 3250 5300
Fax: 07 3250 5399
[mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ]
Re: Are global variables truly global?
-- Chui G. Tey [EMAIL PROTECTED] I have some state data that I need to persist between requests. At the moment these are COM objects, but they'll be ported to Perl Classes. It is quite important that only one of these instances exist per web server. These instances are too large to write and read to file on every request. So I have defined the variable as a package level variable. I have been instantiating the variable in my handler() routine if it has not already been instantiated. ie. Global variables are exactly that: global. If you use something like: our $foo ||= somefunc; or our $foo = Someclass-constructor( @blah ); then you'll get a value that goes into the symbol table and is unique w/in the executing process. Thing you'll need to read up on are global variables, packages/namespaces and how use strict effects things (all of which are in the Camel or Llama books). -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Are global variables truly global?
Will the different child processes created by Apache share the same variable? Or will each child create an additional instance? Each child has a separate interpreter and thus a separate instance of your global. If you need to co-ordinate data between processes, you might want to look at Cache::Cache or MLDBM::Sync. If you just need an exclusive lock, file locking is the simplest way to go. - Perrin
