Fwd: More IO Changes (need feedback)

[Andrew Whitworth]

Heh, Jim pointed out that I didn't cc this to parrot-dev. Doing so now.

--Andrew Whitworth

---------- Forwarded message ----------
From: Andrew Whitworth <wknight8111 at gmail.com>
Date: Wed, Nov 21, 2012 at 9:29 PM
Subject: Re: More IO Changes (need feedback)
To: James E Keenan <jkeen at verizon.net>


On Wed, Nov 21, 2012 at 8:49 PM, James E Keenan <jkeen at 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