[tpm] fork and blessed hash references

Fulko Hew fulko.hew at gmail.com
Thu Jan 14 07:49:57 PST 2010


On Thu, Jan 14, 2010 at 10:39 AM, Madison Kelly <linux at alteeve.com> wrote:

> Hi all,
>
>  I want to put a shutdown timer on a spawnable daemon (specifically, a
> script spawned by dbus). To do this, I created a bless'ed "self" hash
> reference in my module's constructor, set a few time values in it and the
> call a timer method. In the timer method, I 'fork' and the child starts a
> loop and the main script returns and waits for method calls over dbus.
>
>  The problem is that, in the child process, changes to the values in 'self'
> made by the parent do not appear in the child. Specifically, each method
> call changes a '$self->{SHUTDOWN_TIME}' value. I can understand this
> behavior to an extent, but when I print out the hash reference itself both
> in the parent and the child, they have the same reference string. Obviously
> though, they aren't actually using the same memory space.
>
>  So two questions;
>
> 1. Why do the self references match when they don't (apparently) use the
> same memory space
>

Because a forked process contains a 'copy' of the parent process.  Since its
an exact copy, it
effectively has exactly the same memory addresses. (but they are in a
separate instance of memory space)

>
> 2. What is the best way to "share" variables between children and parents?
>

Pipes, shared memory, files, sockets, etc.  There is no 'best' way.
Originally forked process (parent/child) were intended to be 'very
independent'
and hence don't 'share memory', and are protected from the other's 'bugs',
and your only choices are the ones above.

Then the world invented threads, where everything runs in the same process
space
and effectively shares everything, were one thread can accidentally (bug)
walk over
everything.

Currently I am working around the problem by writing out my timing info to a
> tmp file,

but this seems to be unnecessarily expensive.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/toronto-pm/attachments/20100114/229c6902/attachment.html>


More information about the toronto-pm mailing list