At 11:01 AM 4/25/2001 -0300, Branden wrote:
>At 09:39 AM 25/04/2001 -0400, Dan Sugalski wrote:
>>At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>>>I think we definitely have to be able to resize vtables at compile time,
>>>which is a form of run time. It's vaguely possible we could restrict
>>>multithreading during compile phase.
>>
>>We need to be single-threaded when we make any sort of wholesale
>>structural change to the universe. It's a lot easier (and cheaper) to do
>>it during a period where we're guaranteed to be single-threaded than it
>>is to have all the running threads go stop and check periodically. (I
>>don't really want to be coordinating on mutexes every statement or block
>>or whatever)
>
>Are we really willing to pay the price and handle the complexities of
>*resizing* vtables?
If the ROI is high enough, sure. Outside of the multithreaded issues, it's
not all that tough. Some reallocs and a quick search-and-replace run over
the PMC arenas.
>If the idea is supporting arbitrary add-on operators, which I believe will
>be done seldom, for only some specific classes, wouldn't it be better to
>have a ``catch all'' entry for operators different than the built-in ones?
That would be an option, sure. It's slower, though, which is one of the
things we're looking to avoid.
>Of course, add-on operators would not have the same ``performance'' of
>built-in ones, but:
>
>1) We don't have to add an entry to *all* vtables for each operator we
>want to add to a *specific* class.
We need at least enough entry to pitch a fit if the vtable method is called
for a class. Though if we hide all the overflow in a single catchall entry
that's easy enough to do.
>2) Anyway, even resizing vtables we would need some more indirection to
>determine in which position of the vtable is which operator.
No. Each operator goes in a fixed position in the vtable, and it's the same
for each table. Anything else is nasty, error prone, and slow.
>3) We wouldn't have to deal with the complexities of resizing vtables.
>
>4) Having one only vtable entry as a ``catch all'' would allow defining
>new operators ``on the fly''. For example, I try to use the theta operator
>between two bignumbers. Even if theta wasn't defined, it would call the
>``catch all'' of the bignumber vtable, that could do a search à la
>AutoLoader, or even define the operator based on the Unicode number of the
>symbol theta, or anything like that.
The other thing to consider is whether a vtable method is needed at all, or
if what's really needed is another opcode. The opcode table will also be
extendable and overridable, though it shares the same issues of thread
safety as the vtables do. (Though it's much easier to handle, as there's
only one table that can be protected by a mutex, and the interpreters can
certainly make sure that update access is properly synchronized, and we can
also make sure we don't deploy any perl bytecode that requires the updated
opcode table until the update is completed)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
