in reply to to "use vars" or not to

$dbh, $timestamp and $server don't sound like variables that should be used from outside the package, so use vars isn't appropriate. They don't sound like they need to be package variables, so our isn't appropriate. my should be used here. (Actually, it would probably make a lot more sense for those to be attributes of any object.)

variables defined by “use vars” can end up being shared between the forked children ?

Variables aren't shared between processes. Each child gets a byte-for-byte copy.

I am occasionally having mangled data go into the database

It doesn't make sense for two processes to use the same database connection. Open a connection in each child.

Replies are listed 'Best First'.
Re^2: to "use vars" or not to
by westy032001 (Novice) on Nov 08, 2010 at 18:03 UTC
    Thank you for your quick response .

    All of my DBI code exists in the module run by the child forked from the listener and so I dont intend to share a connection, but by setting the $dbh globaly in the module run by the child am i causing it to be inherited by the next forked child ?

    thanks.

[reply]

      You seem to be unclear about what fork does, in Perl and on many operating systems. See Fork (operating system) for a more general introduction. If you are on Windows, it's best to avoid fork overall, especially when trying to use DBI.

[reply]
        Thanks again for the reply and link.

        So to summarize, creating a global (via use vars) $dbh database handle in a module called from a forked child cannot impact another forked child because the child is a copy of the parent prior to the creation of the $dbh. ?

        hopefully thats right ? cheers.
[reply]

In Section Seekers of Perl Wisdom