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.
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.
PMC methods ----------- ParrotIO has methods via find_method/invoke. Should that be a general mechanism in default.pmc with one vtable slot for the meth hash?
We're going to want lexially nested method caches, so I don't think we're going to want to do this. The method hash needs to be living in the interpreter struct, alas.
Calling Conventions ------------------- The return value convention needs some more thoughts. While the caller knows everything about how it calls a sub, it may or may not know, how the sub passes return values.
The caller needs to inspect the return value indicators to see what it got back. The only potential issue is ordering when a sub returns mixed types, though we could if we wanted to just forbid that for right now. It's either that or we have to pass back a return signature.
Exceptions ---------- I presume internal_exception() should throw a real exception. So the exception reason should be classified (severity/reason).
Yep. Internal exceptions are generally pretty severe, but they certainly aren't all that bad.
Resumable ops and exceptions ---------------------------- For example the C<loadlib> opcode currently PANIC()s, if the library couldn't be opened. Such opcodes could be changed to throw an exception on failure and allow resuming on the next opcode. Related: Subject: Trapping find_lex failure; case for search_lex? And of course: Don't Panic!
Yes, you're right.
Vtables ------- Almost warnocked: Subject: [RfC] disable unused vtable entries
Not warnocked--leave these in for right now.
Vtables 2 --------- Are there any design hints on var/value split of vtables? Currently in a lot of places the address of the vtable is used to check if a class is e.g. a PerlInt. This will not work if that is a tied PerlInt. Other checks are done with vtable->base_type, but a tied PerlInt will have a different class enum too. So how will we check for "some PerlInt" class? What is the subtype? And what are int_type, float_type, num_type, string_type in the vtable?
I'm still working on these, and as part of it I'm trying to come up with a good way to allow layered vtables that aren't horribly expensive in terms of memory and time.
Event handling -------------- Should I rediff and commit [perl #23039] [PATCH] event handling-2
That I need to go take a look at. Hold off on it for right now. -- Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
