Geoffrey Young wrote on 5/3/04, 8:02 PM:
> > Example 2:
> >
> > Basically the same except I have a C handler defined for TypeHandler
> and
> > a mod_perl handler defined for FixupHandler. When the C code does:
> >
> > ap_table_set(r->subprocess_env, "TEST", "value");
> >
> > The mod_perl handler for FixupHandler doesn't see it using:
> >
> > $something = $r->subprocess_env("TEST");
> > However, as mentioned in many of the docs/books, this is expensive
> and I
> > really only need the one variable.
> >
> > I've also tried walking the subprocess_env table in the perl handler,
> > but the value set in the C handler is not there.
>
> that's really strange. are you sure that you are not removing it in your
> application someplace? try tweaking the test tarball I mentioned bit
> by bit
> until it has the relevant logic from your code in it. I can't tell
> you the
> number of bugs I've "fixed" by trying to reproduce the bug, only to
> find I
> was the bug :)
Geoff,
So I haven't been able to get very far on the code to test this further,
but in the Eagle book I noticed this (section 9.1.4):
"subprocess_env() is only required if you need to change the environment
in a subprocess launched by a different handler or module."
So what would happen if the C module is setting it's own ENV instead of
using ap_table_set? Would that explain why I can't see the value in the
perl module using subprocess_env, but when I call void subprocess_env(),
the value suddenly appears in %ENV and the subprocess table?
--John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
