-----Original Message----- > Date: Fri Jan 23 09:27:12 EST 2004 > From: "Dan Sugalski" <[EMAIL PROTECTED]> > At 10:37 PM -0500 1/22/04, Benjamin K. Stuhl wrote: > >Dan Sugalski wrote: > >>In addition to the thread autolocking front end and debugging front > >>end vtable functions, both of which can be generic, there's the > >>potential for tracing and auditing front end functions, input data > >>massaging wrappers, and all manner of Truly Evil front (and back) > >>end wrappers that don't need to actually access the guts of the > >>PMC, but can instead rely on the other vtable functions to get the > >>information that they need to operate. > >> > >>Not that this necessarily mandates passing in the vtable pointer to > >>the functions, but the uses aren't exactly marginal. > > > >Going back to the idea of generating these vtables on the fly (and > >caching them): each instance of a vtable gets a void* closure in the > >vtable itself, > >so at a certain expense in extra vtables, one could hang a structure off > >of that that includes a pointer to the original vtable. > > Which I thought of, but that only allows for one layer of > indirection, and doesn't allow the original vtable to hang any data > off its vtable data pointer. (Which exists, and is there for that > very reason) If you have two or three layers of vtable functions > installed then it becomes difficult and time-consuming to find the > right data pointer--if you allow the same vtable to be layered in > multiple times (and no, I don't know why you'd want to) then it > becomes essentially impossible. > > Unfortunately the layers need to stay separate with separate data > attached, so if we allow layering and don't forbid the same layer in > there twice we have to pass in the pointer to the vtable actually > being called into, so the vtable functions can find the > layer-specific data.
Well, that was why I had my suggested sample pseudocode restore the previous vtable pointer before calling down to the next function (and put itself back when that's done). This means that every vtable function knows that PMC->vtable is the vtable _for the current vtable function_, and so any vtable function can be confident that it is accessing the corect layer-specific data. It's a bit more complexity and 2 extra assignments in the wrapper vtable functions versus an extra parameter to _all_ vtable functions. -- BKS
