On Fri, Apr 30, 2004 at 06:25:50PM +0200, Leopold Toetsch wrote: > Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > This is true. And yes you need to set a stack top if you're expecting the > > stack walking to find things you own. But I'm thinking about the case where > > the embedding app registers all its PMCs immediately, and so doesn't expect > > (or want) to be stack walked. > > Each PMC allocation can trigger DOD and or GC. If you never free any PMC > until program termination, you can turn off both DOD and GC. I doubt > that this is a reasonable scenario, though. And if you "unuse" PMCs and > DOD is off, you'll quickly run out of resources because recycling can't > be done then. > > If you really don't want to rely on stack walking, you have to register > each PMC with C<Parrot_register_pmc()>. This function uses a hash for > remembering the PMC's address. So it's not really fast. But I suspect that there will be embedders of parrot who want to do this - register only 1 or 2 PMCs that they use to hold configuration or state, and hold onto these outside the runloop. They'd then make calls into the runloop to get stuff done. Effectively this allows the embedding app to provide subroutines/functions that appear to the caller to be written in C, but actually have a parrot implementation. But the implementation language is an implementation detail. > > Prefixing all the linkable functions as Perl_ or PerlIO_ etc > > Ugly. Can't the linker hide it? Probably yes on most platforms, but the usual problem for perl is that it has to remain horribly portable, and it has to be portable to platforms that aren't currently available for any of the porters to test on. So fun things like Crays (Where sizeof(short) is 8) Nicholas Clark
