[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