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

Reply via email to