Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:17 PM +0200 7/13/03, Leopold Toetsch wrote:
>>
>>I think one Env PMC ought to be enough. And that one may have e.g. an
>>Iterator ettached, which simplest is done by deriving it from an hash
>>like PMC.
> Potentially, yes. We still ought not cache, since otherwise process
> environment changes made outside the interpreter won't register with
> us, which would be bad.
Which is AFAIK only possible for Win* and VMS.
We could do something like this:
init: PMC_data = NULL
cache.struct_val = NULL
getenv: Parrot_getenv;
setenv: Parrot_setenv; if (PMC_data) SUPER.set_string_keyed()
unsetenv: Parrot_unsetenv; if (PMC_data) SUPER.delete_keyed()
iteration init:
p = NULL;
if (!PMC_data || cache.struct_val != (p=Parrot_all_environ())) {
cache.struct_val = p ?: Parrot_all_environ()
build hash from this
}
SUPER() ...
Parrot_all_environ() is a function returning the current char *envp[] as
a NAME=value string array.
#ifdef linux
# include <unistd.h>
# define Parrot_all_environ() __environ
#endif
This would allow caching as long as the Parrot_all_environ() returns the
same pointer and the hash is built only on demand i.e. for accessing
the whole %ENV. Iteration would use the hash (no changed keys of process
environment during iteration are reflected in the env hash).
leo
