Fake handles (was: Re: New VMMaker/svn release)

[David T. Lewis]

On Wed, Jan 04, 2006 at 07:22:43AM -0500, David T. Lewis wrote:
> On Tue, Jan 03, 2006 at 10:41:29PM -0800, Andreas Raab wrote:
> 
> > And now that we got this done ;-) we can start talking about how to 
> > expose the functionality that you need in a nice and cross-platform way. 
> > Like, accessing standard file handles: What's wrong with a 
> > primitiveGetStdFileHandle that takes an integer argument for the kind of 
> > standard handle to retrieve (0 - stdin, 1 - stdout, 2 - stderr)? Sounds 
> > simple enough to me. Any others you'd need?
> 
> I don't really like the 0, 1, 2 convention, because it's an ancient
> Unix convention, and really they are supposed to be treated as
> opaque handles (seriously). It's probably OK to implement primitiveGetStdOut,
> primitiveGetStdErr, and primitiveGetStdErr in the FilePlugin as long
> as they are optional primitives and fail in reasonable ways.
> that these are really still unix conventions that have been adopted
> elsewhere, and may be rather platform-dependent. They behave differently
> on Win32 and unix, and I don't know what RiscOS does about them. Tim?
> 
> Pipe handles are definitely needed, and given Squeak's current approach
> to files and sockets, these should be treated as file handles. Anonymous
> pipes don't have path names, so the process of opening them is of course
> different.  Pipes are very platform-dependent, and I'm not sure this
> belongs in the core plugins. I'll see if I can think of a way to do
> this that is not too "evil" ;)

After giving this a little more thought, I can see two feasible ways
to expose the required functionality while still allowing OSPP to exist
as as optional external plugin.

1) Move primitiveCreatePipe, primitiveGetStdIn, primitiveGetStdOut, and
primitiveGetStdErr out of the OSPP plugins and into FilePlugin, and sort
out the platform differences in the support code. 

2) Have FilePlugin provide a primitiveOpenHandle that could be invoked
in a manner similar to the current StandardFileStream>>primOpen:writable:,
except that the supplied parameter would be something representing a (HANDLE)
or (FILE *), e.g. "primOpenHandle: aByteArray ofLength: 4 writable: true".

Option #1 is undesirable because both the concepts and the implementations
are quite platform-specific. But it is workable as long as the VM maintainers
don't mind, and as long as at least the Unix and Win32 implementations
actually get done.

Option #2 would work well, but does not address the security concern. If
spoofing a fileID is a security concern, then spoofing a HANDLE would
presumably be equally bad. But it does at least get rid of the outside
manipulation of private data structures.

In either case it would be helpful to add a primitiveFileHandle that
answers the platform-specific (HANDLE) or (FILE *) corresponding to the
certified, non-fake fileID. This would be used by platform-specific
extensions (e.g. file locking, fcntl functions) and would eliminate
the need for knowledge of the SQFile struct in other plugins. Ditto
for the SocketPlugin, if only for the sake of uniformity.

>From my own point of view, either of these would be OK. I also have no
objection to leaving things as they are, although I would prefer that
the various FilePlugin implementations use the same sessionIdentifier.
The workaround I've had to use for the last few years is truly awful.

Dave