[Vm-dev] VM handle management
David T. Lewis
lewis at mail.msen.com
Wed Mar 24 14:51:33 UTC 2010
On Wed, Mar 24, 2010 at 03:31:39PM +0100, Bert Freudenberg wrote:
>
> On 24.03.2010, at 13:40, David T. Lewis wrote:
> >
> >
> > On Tue, Mar 23, 2010 at 08:10:18PM -0700, Andreas Raab wrote:
> >>
> >> Folks -
> >>
> >> [Warning: Long post. Please try to stay on topic and don't get into any
> >> SmartSyntaxInterpreterPlugin / FFI syntax digressions that always come
> >> up with these issues. This is a practical proposal that I'd like to
> >> implement].
> >>
> >> For the third time this month I ran into the situation that I was
> >> writing a plugin that would create an internal data structure
> >> (containing pointers etc) and where I wanted to return a handle to this
> >> structure and pass that back to the VM.
> >>
> >> Since I'm a lazy bastard, what I usually do is something like this in
> >> the support code:
> >>
> >> int sqNewFooBar(void) {
> >> /* creates a new foobar and returns a handle */
> >> FooBar *newFoo = malloc(1, sizeof(FooBar));
> >>
> >> /* return a handle, sort of */
> >> return (int) newFoo;
> >> }
> >
> > This seems like solving the wrong problem. If the problem is
> > that pointers cannot be treated as sqInt or OOP values, then
> > the solution is simple: Don't Do That. Declaring the types
> > properly (in slang where necessary) results in simpler slang
> > and simpler support code overall. That is my actual experience
> > after working through quite a few 64/32 bit issues, not just
> > a theoretical statement.
>
> No, that's not the problem. The problem is having to implement a handle
> registry over and over again, for many plugins. Whenever a plugin needs
> to store some dynamic state, you end up writing this again. I've seen
> this with Cairo surfaces, Freetype fonts, DBus connections, OpenGL
> contexts etc.
Ah, I see. That sounds fine then.
Dave
More information about the Vm-dev
mailing list