At 12:43 +0200 7/30/03, Leopold Toetsch wrote:
I have started looking at dynamic classes. I have currently - new subdirectory /dynclasses - small hack for classes/pmc2c.pl to consider this directory too - dynclasses/foo.pmc, dynclasses/Makefile (unportable, but short ;-)
Here's what I was thinking instead.
We build classes as shared libraries, unless otherwise noted. PMC libraries get loaded up with an op--load_pmc or something of the sort. It takes a PMC name and tacks on the library prefix and suffix as need be. We load in the PMC library, call its setup routine, call its initialization routine, and let it do its thing. The setup routine, when called, will at the least register the PMC's class in the class name hash. There should be some code in the system to manage this, though it needs mutex protection.
Eek? Forcing a new DLL for every dynamically-loaded PMC class? So many open()'s and persistent file handles and mmap regions! As if Perl 5's DynaLoader weren't bad enough already. I can hear the clatter of keyboards across the world. I can't make out the rest, but it all starts with su and then echo `perl -e 'print 2**32-1, "\n"'` > /proc/sys/.... Maybe this is one way to go, but please don't make it the only one; administrators of fork()-based server programs the world over will thank you from the bottom of their hearts.
I'm speaking from the side-lines, but why not have a DLL register all the PMCs it contains at load time (placing the onus of setup on the library author rather than the parrot core)? The library could put into global variables whatever identifiers/data structures support the dynamic PMC allocation. Sharing of the PMC class would then be equivalent to visibility of those globals--equivalent to having linked with the library containing the PMC definition--and so PMC class versioning is thereby solved to the same extent that library versioning is solved by the dynamic linker. Also, if the PMC class global is visible to user code, then it's already registered and that code doesn't need to do anything special at all to load it up.
I suppose this screws up in the single process/multiple interprete (SPMI?) scenario, since the dynamic PMC could need to appear in a different slot on each interpreter. But if the DLL was itself loaded only through the interpreter itself, and the interpreter communicated to the library's initialization routines? (Worst case means of communication: Giant spinlock around library loading, plus a current_parrot_interpreter global in the parrot library, which the DLL is of course linking against.) Then a sufficiently private mapping or per-interpreter initialization might be possible, depending on dynamic linker's capabilities.
—
Gordon Henriksen [EMAIL PROTECTED]
