On 10/19/11 1:05 PM, Ethan Quach wrote:
On 10/19/11 11:34, Drew Fisher wrote:
On 10/19/11 12:21 PM, Ethan Quach wrote:
Drew,
Just a question here but do we need to account for a situation where
those env variables were already set in the environment for other
purposes? i.e. do we need to record existing values if they
existed, and then set them back into place when this chunk is done
rather than just clearing them?
We certainly could check for them, but these are not common
environment variables to set. We're not checking for their existence
with the configure_smf() method, either.
What do you think? I'm not sure on this one.
Understood about the uncommon usage of those variables, but the
question was more around the execution order of other functions during
the entirety of the DC process. ie could there, or would there, ever
be some other place in the DC process that sets and relies on one of
those vars, and then by chance your new code is run, and then when it
returns the var is gone? If we know that won't ever happen because
reasons XYZ, then that's fine. In general though, it seems like
manipulating env vars in the main stream of execution without
purposeful intent on its affect to the entire process is subject to
looming and/or hard-to-diagnose bugs.
I totally agree. I think moving the needed environment variables into
the run() calls will protect us from things like this. I'm also going
to change configure_smf() in the same way. I need to retest, so it'll
be a bit before I can get another webrev out.
-Drew
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
