Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote: > At 14:17 +0100 12/21/03, Leopold Toetsch wrote: >>1) a real global Parrot_base_vtables[] containing pointers to the local >> *static* temp_base_vtable inside the PMC classes C file. >>2) another per interpreter vtable array holding all dynamic entries >> >>Access to the former is per index like now, for the latter, the index >>has to be obtained once at tuntime per name lookup.
> I'm not sure the per interpreter vtable array should exist at all > until it is needed. It is there - emmpty, NULL ;-) Then, after registering a dynamic type, its allocated and filled with data. When then a thread is started, this tables is copied - COW at best. > ... One of the things people use threads for, is to > have many, many worker threads doing the same thing. The way to do > this would be to start 1 thread that sets up all of the specific > worker related changes to the global environment, which would set up > the per interpreter vtable array. Then all threads started from that > thread would use exactly _that_ structure (without any copying or > cloning or anything). That is, if I'm understanding what vtables do > correctly. Yes, but we don't know in advance, if any thread will register some class and another thread a different one. Its unlikely, so a COWed copy fits best. > Not copying anything is what threaded applications in general make > such a good thing (and copying everything for each thread is > currently what makes Perl 5 ithreads such a badly performing threads > implementation). I don't see a big problem with interpreter internal data structures. Copying user data i.e. PMCs can be time consuming. E.g. you have a huge set of input data, and you start some threads, to work on different parts on that input data. Ideally these data should be marked shared and constant to avoid copying as well as locking - or the optimizer is able to analyse all usage of these input data and doesn't see any alteration. > Liz leo
