Heh, Jim pointed out that I didn't cc this to parrot-dev. Doing so now. --Andrew Whitworth
---------- Forwarded message ---------- From: Andrew Whitworth <wknight8...@gmail.com> Date: Wed, Nov 21, 2012 at 9:29 PM Subject: Re: More IO Changes (need feedback) To: James E Keenan <jk...@verizon.net> On Wed, Nov 21, 2012 at 8:49 PM, James E Keenan <jk...@verizon.net> wrote: > One thing: Could you expand a bit on this? > > >> 2) whiteknight/io_vtable_lookup In Parrot master, we lookup >> information about the IO_VTABLE and the read/write IO_BUFFERs using >> VTABLE_get_pointer_keyed_int. This is a bad system. > > What specifically is bad about it? Good question. The pointer-related vtables (get_pointer, get_pointer_keyed_*, set_pointer, set_pointer_keyed_*) are a little problematic. First, they can only be used at the C-level, not at the bytecode level. User-defined types in PIR/NQP/Rakudo can't use these vtables. This means that, for the current IO system, objects defined at this level are second-class citizens and can't participate in all the IO functionality. If we really want the IO system to be polymorphic and type-agnostic, it needs to only rely on functionality which is available to ALL objects, not just our in-built C level ones. There's also the more abstract problem that these vtables operate on void* pointers, not typed pointers. Because of this, different PMC types may return different types of pointers to different types of things. This is a necessary evil for something like NCI where an Integer PMC should return an int* pointer and a Float PMC should return a double* pointer, etc. But IO_VTABLE and IO_BUFFER are parrot-internal implemenation details that shouldn't pass to NCI or anywhere else for that matter. They only matter inside the IO code, but VTABLES are visible from all sorts of other places that might be tempted to access them. This branch only partially resolves this issue, mostly by passing the buck from the various Handle PMCs (FileHandle, StringHandle, Pipe, Socket) to a new IOBuffer PMC which implements VTABLE_get_pointer, this isn't so bad when you consider the third problem... The third problem is that in the current IO implementation VTABLE_get_pointer_keyed_int returns an IO_VTABLE* sometimes and an IO_BUFFER* other times, depending on the key value passed. This creates all sorts of potential for mayhem, if we aren't extremely careful about what pointers we're expecting, what key values we're passing, and what things we're dereferencing. By having IOBuffer PMC always return an IO_BUFFER* from the VTABLE_get_integer and not returning different types of pointers at different times, we can be a little bit more certain about these operations. I hope that helps. This new solution isn't perfect (there may not be a "perfect" here) but I think it's going to be much better than the current system (which is, in my opinion, already a big improvement over what we had before). It's all about incremental improvements. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev