--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 07:30 AM 12/30/2001 -1000, David & Lisa Jacobs wrote: > > >From: "Dan Sugalski" <[EMAIL PROTECTED]> > > > At 08:33 PM 12/29/2001 -1000, David & Lisa Jacobs > wrote: > > > GC will manage all the memory. Everything managed > should either be hung > >off > > > a PMC or an internal structure. (There are GC hooks > in the vtable for > > > complex things) > > > >So does that mean I can get rid of passing around the > interpreter? > > Sort of. Memory and structure (pmc header & string > header) allocation must > be from interpreter-local pools. There's a patch to use > TLS for the > interpreter pointer rather than passing it as an > argument--I've pretty much > decided it's The Way To Go, so I'm going to dig it out > and apply it. > > So you still need the interpreter pointer, you just don't > have to pass it.
Are you really sure about this? The reason perl5 threads are MULTIPLICITY-based (pass around an interpreter pointer) is that Sarathy got a noticeable speedup from not having to call pthread_getspecific() every time he needed to allocate memory or look up a symbol. It can be good to have _nocontext functions that who fetch the interpreter when it's really needed (e.g. to throw an error), but do we want to have to make an extra library call of unknown efficiency on _every_ call to string_make()? -- BKS __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
