[Vm-dev] discuss: [Squeak 0001144]: [ENH] SmartSyntaxInterpreterPlugin

[David T. Lewis]

On Sun, Aug 20, 2006 at 11:40:44AM +0200, Martin Kuball wrote:
> Am Sunday, 20. August 2006 00:16 schrieb David T. Lewis:
> > I don't remember having done this in OSProcessPlugin. I did lots of
> > other horrible things, but I did not pass any C pointers to or from
> > primitives.  Signal handlers, aio event handlers and the like require
> > function pointers, but there is no need pass these pointers to or from
> > the image.
> 
> Well here's what I understand by looking at your code. Let's take 
> primitiveCreatePipe. It returns an array with two ByteArrays in it that 
> contain information about the reader and the writer of the pipe. Let's 
> take the first ByteArray, the writer. You create it, take the pointer to 
> the bytes and interpret them as a struct of type SQFile. Than you set the 
> field "file" inside the struct to the value of writerIOStream which is (on 
> unix) a pointer to a FILE structrue optained from a call to fdopen.
> 
> 	writer _ self newSQFileByteArray.
> 	writerPtr _ self fileValueOf: writer.
> 	self cCode: 'writerPtr->file = writerIOStream'.
> 
> So to me this looks very much like you'r passing pointers to C data 
> structures to the image. But I admit that I might still not really 
> understand this plugin stuff.

Martin,

Well, in a way you are right. What I am doing here is creating a
ByteArray that will be used as the fileID instance variable of a
StandardFileStream.  The fileID is intended to be treated as an
opaque handle on an operating system file. This handle happens
to be implemented as a copy of the data in a SQFile data structure,
and it includes a pointer to the operating system's file pointer
(either a *FILE or a *HANDLE, depending on the OS). But nothing
on the image side is actually making use of that pointer, it just
happens to be part of the data in the ByteArray that is used as
an opaque handle.

I should note that Andreas has raised an objection to the idea of
creating the fileID outside of the FilePlugin. Strictly speaking,
he's right that it's a Bad Thing To Do, although as a practical
matter it enables me to maintain OSPP and OSProcess independently
of the FilePlugin. I'd like to address this if I could think of
a clean way to do it, but I can't think of any cure that would
not be worse than the disease.

Dave