Em Dom, 2008-12-28 às 00:31 -0500, Jeff Horwitz escreveu: > the modules it uses assume they're embedded in an apache process, > dlfunc'ing a bunch of apache API functions.
I think that means the 'dlfunc' calls need to be in INIT and not in BEGIN. > right now it is impossible to compile such a module to bytecode, which > i like to do for startup performance. This is actually something I've been thinking for a long time. The thing is that in Perl 6, besides all the efforts, the difference between compile time and run time is not that clear. The thing is that the usual aliasing of symbols from outer modules to this module can be understood as "static linking", which can raise issues with modules that cannot be "statically linked". In a "dynamic linking", the foreign module only need to declare which symbols it will provide (i.e. a '.h' file) at compile time, and the compiled object simply contains a reference "this symbol belongs to X". Then, at run-time, you will load the used module and resolve the symbols that you linked in this code. I think this means we need to have two compiling modes, one to generate the "header file" and other to generate the "executable file", or at least we need a way to extract the "header"s from the "executable file" without actually loading it. The problem is that "use" calls EXPORTALL on the package being loaded, and there the barrier between compile-time and run-time becomes very much blurred, because to run EXPORT on the given module, it must be entirely loaded, and I presume the call to EXPORT can only happen after INIT has already been called in that module. I think that's a deadlock. daniel
