Dan Sugalski <[EMAIL PROTECTED]> wrote: > For PBC code, this is where metadata comes in. (Which means we can > potentially use it for on-the-fly assembled code as well) If a segment of > code is known to need an opcode library, then the bytecode loader should > make sure that library is loaded, instantiated, and that the opcode table > for the code segment is properly filled in.
Yes. When metadata -> Constant PMCs -> freeze/thaw -> VTABLE_traverse() (sic!) is done, the bytecode loader can take care of loading needed resources. This gives an extra bit of security, as the necessary ordering of resources is always done in the assembler. If a C<loadlib> opcode is found, the assembler prepares the metadata (which are in correct order then) for runtime. For on-the-fly running the metadata are prepared but unused, as the loading has already been done (PMC and oplibs). So its always guaranteed that dynamic resources are loaded in the same sequence, that is the sequence that the assembler sees. When it comes to multi-threaded programs that try to load different PMCs (or oplibs) in their execution forks, we will have some fun... > Dan leo