Re: [mp1] subprocess_env and non-mod_perl handlers
> Example 1: > > I have mod_perl handlers defined for the TypeHandler and FixupHandler > phases. If in the TypeHandler code I do this: > > $r->subprocess_env("TEST" => "value"); > > Then in FixupHandler I can "see" TEST using: > > $something = $r->subprocess_env("TEST"); > > Which is what you would expect. indeed. > > > 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"); that's not right. however, I can't reproduce this with the attached minimal test case. see http://perl.apache.org/~geoff/subprocess-env.tar.gz > > > If I do the void subprocess_env trick: > > $r->subprocess() > > before retrieving $something, then it's populated along with the rest of > the environment. that only affects %ENV, not the ability of $r->subprocess_env to grab something from the subprocess_env table. %ENV is not automatically populated with the contents of subprocess_env, so if you're really talking about %ENV then your Example 2 + subprocess_env() trick sounds right. > > 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 :) > > Are the C API subprocess_env table and the mod_perl API subprocess_env > table distict until something (like the void call) merges the tables? Is > this some sort of scoping issue between C and Perl? it shouldn't be, so long as you're hitting the tables directly with $r->subprocess_env. %ENV is another matter entirely. --Geoff -- 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
Re: [mp1] subprocess_env and non-mod_perl handlers
Geoffrey Young wrote on 5/3/04, 8:02 PM: > > If I do the void subprocess_env trick: > > > > $r->subprocess() > > > > before retrieving $something, then it's populated along with the > rest of > > the environment. > > that only affects %ENV, not the ability of $r->subprocess_env to grab > something from the subprocess_env table. %ENV is not automatically > populated with the contents of subprocess_env, so if you're really > talking > about %ENV then your Example 2 + subprocess_env() trick sounds right. Nope, I'm talking about the table itself (via subprocess_env), which is why I am confused. > > > > > 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 :) Understood. :-) Thanks for the code, I'll keep working on it trying to narrow down the problem. At least I know that the behavior I'm seeing is definitely wrong and it should work without the void subprocess_env call. > > > > > Are the C API subprocess_env table and the mod_perl API subprocess_env > > table distict until something (like the void call) merges the > tables? Is > > this some sort of scoping issue between C and Perl? > > it shouldn't be, so long as you're hitting the tables directly with > $r->subprocess_env. %ENV is another matter entirely. Thanks, --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
Re: [mp1] subprocess_env and non-mod_perl handlers
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
Re: [mp1] subprocess_env and non-mod_perl handlers
> 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." what this section is talking about is the ability of mod_perl to alter the environment of other handlers, such as mod_php. in those cases, you are required to use subprocess_env. > > So what would happen if the C module is setting it's own ENV instead of > using ap_table_set? ou're thinking too hard :) there is no ENV in C-land, really. I mean, there are ways to get to perl's %ENV via C but that's not what you say you're doing. so forget about %ENV for the moment - %ENV gets set specifically my modules (mod_cgi, mod_perl, mod_php) based on the contents of the subprocess_env table and has no bearing at all if you're accessing the table directly. > 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? not really. but clearly you have some kind of problem. unfortunately I've never seen this before and I don't see anything in the code to suggest what your problem might be. and if I can't reproduce it I can't solve it. here are a few things to try though. first, see if changing your calls make any difference. that is, use $r->subprocess_env->get() and $r->subprocess_env->set() instead of other forms to remove the tie magic from the equation and see if that helps at all. next I would try fiddling with PerlSetupEnv to see if that has some hidden interaction with your reads. you seem to know some C, so I'd try creating a C content handler and use that to just dump the subprocess_env table. you can use mod_example.c as a guide. if you can see the variable in your own content handler but not when mod_perl is the content handler then I guess that at least verifies something. (what, I don't know :) anyway, if you are able to reproduce the problem and roll it up into the tarball I posted then I could fix whatever it is in mod_perl core that's causing you harm. HTH --Geoff -- 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
Re: [mp1] subprocess_env and non-mod_perl handlers
Geoffrey Young wrote on 5/4/04, 4:18 PM: > not really. but clearly you have some kind of problem. Doh! I definitely do, I think I'm it. Remember earlier when you said how in debugging you often find that you are the bug? Well, I am the bug in this case. :-) In the process of trying to figure out why I wasn't seeing anything in the subprocess_env table, I decided to take a look at the headers_in table. And there it was. Turns out that the C handler I am using (for which I have limited docs) is putting it's data into the headers_in table and not the subprocess_env table. (Insert embarrassed big red face here.) Based on everything I've read on handlers and the types of things being populated (i.e. not headers from the client) the headers_in table didn't seem to be the right place so I wasn't looking there. Sorry about that. Thanks for the help, --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
Re: [mp1] subprocess_env and non-mod_perl handlers
John Wittkoski wrote: > > Geoffrey Young wrote on 5/4/04, 4:18 PM: > > > not really. but clearly you have some kind of problem. > > Doh! I definitely do, I think I'm it. > > Remember earlier when you said how in debugging you often find that you > are the bug? Well, I am the bug in this case. :-) :) > > In the process of trying to figure out why I wasn't seeing anything in > the subprocess_env table, I decided to take a look at the headers_in > table. And there it was. > > Turns out that the C handler I am using (for which I have limited docs) > is putting it's data into the headers_in table and not the > subprocess_env table. (Insert embarrassed big red face here.) Based on > everything I've read on handlers and the types of things being populated > (i.e. not headers from the client) the headers_in table didn't seem to > be the right place so I wasn't looking there. > > Sorry about that. no problem at all :) at least you know a little more about both your app and some apache/mod_perl internals, so it was positive overall. --Geoff -- 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