Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 11:06 AM +0200 8/8/03, Leopold Toetsch wrote: >>This is an unordered list of issues - mainly design questions - about >>the specific implementation of some parts. >> >>Interpreter globals >>------------------- >> >>We have real globals (e.g. Parrot_base_vtables, Env) and per >>interpreter/thread globals (e.g. classname_hash). I think best is to >>have the former attached to the first interpreter and let other >>interpreters just point to these.
> The problem with that is that some of the base stuff needs to exist > before there is a first interpreter, which is why it's global. global_setup.c:init_world() is called with the interpreter, that is under construction. So I don't see a problem to attach real globals to the first interpreter. May be I'm totally wrong with my dynamic PMCs patch. But here is what happend: dynclasses/foo.c had to be linked against libparrot (which has e.g. the global Parrot_base_vtables). Now when loading F<foo_pmc.so> we have 2 of these globals, one inside parrot and one in the shared library. The init function in the shared lib (and code called from there) sees the Parrot_base_vtables of the shared lib, which isn't that one, that shall be extended with the new class. So currently I'm copying these globals around. OTOH, if these globals where attached to the first interpreter, they could be reached with interpreter->first_interpreter. >>IO Handles/PMCs >>--------------- >>Are they real globals? What happens if two threads write to STDOUT/to >>the same file? >>See also: >>Subject: [RfC] Semantics of clone for PIO-objects. > Some IO handles are global, yes, especially ones handed to us by code > embedding parrot. What about C<std*>. Can you be ++verbose about "Some"? leo
