Thanks for the input. I was anticipating a replacement master that
replaced resolv() and friends with "multi loader environment" aware
versions. Presumably, there would be an object that contains the paths and
caches for a given loading configuration along with the original
implementations of resolv() and so forth. The top level functions would
select the correct loader object and then call the appropriate function in
that object.
I hadn't considered using the handler as a way to differentiate.
Bill
On Wed, 24 Dec 2008, Martin Stjernholm wrote:
> There's a bunch of functions in the master that gets called during
> compilation: get_default_module, resolv, handle_include, and
> handle_inherit to name a few. The tricky thing is that all those calls
> simply goes through master()->..., so I guess you have two options:
>
> One is to disable threads, use replace_master, compile and then
> restore (compile() disables threads internally anyway, so that's not
> much of a difference).
>
> The other is to use multiplexing resolv() etc. You could look at the
> handler argument, since that gets passed through to most of those
> functions (but I'm not entirely sure it's always passed). A variant on
> this is to store your local master in a thread local variable. That's
> more reliable.
>
> So it's a bit messy anyway you do it. Grubbas new CompilerEnvironment
> stuff might also be an option, but I'm not familiar with that.
>
>
|