At 07:28 AM 6/17/2003, Jeff Trawick wrote: >William A. Rowe, Jr. wrote: >>At 09:15 PM 6/16/2003, Jeff Trawick wrote: >> >>>Justin Erenkrantz wrote: >>> >>>>Since pre_config doesn't get the process info, we can't use the userdata trick to >>>>prevent double initialization. My solution would be to grow the pre_config hook >>>>to get the process info. But, that can't be what was intended. =) -- justin >>> >>>set an environment variable on first pass to know which pass it is >> >>Won't work across platforms. Across Unix, perhaps. > >where and why, if you have the time (other enquiring modules want to know)?
My bad - setenv() will 'work' on win32 to modify the program's 'C' environment table. Where it falls down is modifying the 'inherited' environment, which must be maintained with SetEnvironmentVariable. Why setenv() on Win32 didn't do this has always puzzled me. By the way, it's _setenv() on win32, unless you link oldnames.lib. But I'm liking Justin's comment that creating "a pool of our own" based on the NULL pool might be the way to go. Some pools need to last a lifetime. My last question for everyone with insight ... I load modfoo.so, which is bound to libfoo.so. Once modfoo.so is unloaded and loaded again, is it really guarenteed that libfoo.so will remain loaded throughout, since it was implicitly loaded by the now reloaded modfoo.so? Bill
