Hi!
I know this is more than a year in the past. But some things take their time and I'v just now resumed my work on the Xvid plugin.
When evaluating my sugested changes, Andreas made the following comment:
The main reason for concern is that this creates a dangerous precedent for plugins. Thus far, all plugins have been "safe" in such that they were used with unforgeable object references. Allowing arbitrary pointers in *plugin* interfaces means that the whole idea of "plugins are secure, FFI is not" becomes moot.
Suddenly we need to be aware which plugins abuse what pointers and I think we should really avoid this. I have not looked at the specific reason for wanting to pass a pointer instead of an object reference but the only reason I can imagine is that the pointer was originally obtained by some FFI call. In which case I'd say "stick with FFI" instead of plugins (after all it's no harder to export a C function from a plugin than to write the named primitive).
There are no good reasons that I can think of to suddenly start using C pointers in plugins (lazyness on behalf of the plugin writer does not count) and there are many good reasons against it.
Unfortunately I do not realy understand his arguments. From the code of the plugins that come with VMMaker I can see that there are plugins that use c-pointers and do pass them to smalltalk. E.g. the Mpeg3 Plugin does it and the OsProecess plugin is another example.
I would be very glad if someone could explain to me what is allowed and what is forbidden regarding this matter.
Thanks.
Martin
On Sat, Aug 19, 2006 at 09:17:11PM +0200, Martin Kuball wrote:
When evaluating my sugested changes, Andreas made the following comment:
There are no good reasons that I can think of to suddenly start using C pointers in plugins (lazyness on behalf of the plugin writer does not count) and there are many good reasons against it.
Unfortunately I do not realy understand his arguments. From the code of the plugins that come with VMMaker I can see that there are plugins that use c-pointers and do pass them to smalltalk. E.g. the Mpeg3 Plugin does it and the OsProecess plugin is another example.
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.
Dave
Am Sunday, 20. August 2006 00:16 schrieb David T. Lewis:
On Sat, Aug 19, 2006 at 09:17:11PM +0200, Martin Kuball wrote:
When evaluating my sugested changes, Andreas made the following
comment:
There are no good reasons that I can think of to suddenly start using C pointers in plugins (lazyness on behalf of the plugin writer does not count) and there are many good reasons against it.
Unfortunately I do not realy understand his arguments. From the code of the plugins that come with VMMaker I can see that there are plugins that use c-pointers and do pass them to smalltalk. E.g. the Mpeg3 Plugin does it and the OsProecess plugin is another example.
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
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
Am Sunday, 20. August 2006 16:57 schrieb 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.
I can see the pros and cons. And I have no answer. But at least I get the feeling that I'm on the right track to understaning the stuff. And my xvid plugin is coming along very well. This time without using any FFI classes and without vmmaker modifications ;).
Martin
On Sun, Aug 20, 2006 at 09:18:39PM +0200, Martin Kuball wrote:
I can see the pros and cons. And I have no answer. But at least I get the feeling that I'm on the right track to understaning the stuff. And my xvid plugin is coming along very well. This time without using any FFI classes and without vmmaker modifications ;).
Great, glad to hear it. I don't know much about xvid, but this sounds like a very worthwhile project.
Dave
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Martin Kuball