New proposal: driver objects (in same track as driver_mkref)

[Shawn Pearce]

So i was just thinking about this whole driver_mkref() discussion we had
a few days ago...

Yes, it would be nice to be able to send a reference back to Erlang.  But it
would also be nice to be able to send back a pointer which is not mutable
by Erlang.

There was some discussion about how it could be dangerous for a driver to
return a reference, as that reference might not be unique, unless the
driver used the same allocation scheme as Erts.

But what about the dangers of drivers returning pointers (and other
driver private information) to Erlang as integers or binaries?  These
terms are easy to "manipulate" in Erlang, allowing an Erlang application
to potentially send a bad value to the driver.  So the driver author
must code somewhat defensively.

This is really out on a limb, but what about being able to do something
such as:

	Window			w = XCreateWindow(...);
	ErlDrvObject	obj1 = driver_mkobject(port, w);
	ErlDrvObject	obj2 = driver_packobject(port, &w, sizeof(w));
	ErlDrvTerm[]	term = {ERL_DRV_OBJECT, obj};
	driver_output_term(... term ...);

	....
	Window	w2 = (Window)driver_getobject(obj);

	...
	Window w3;
	driver_unpackobject(obj, &w3, sizeof(w3));

Objects are terms in Erlang, perhaps printed as "#Object<#Port<0.15>.805243a0>>".
It should not be possible to create object terms in Erlang, as they cannot
be mucked with for the sake of driver safety.  Objects can hold any size of data
needed by the driver, but would in general hold pointer sized data.  In the concept
above, I show a pair of functions for pointer sized data, and a second pair for
variable sized data.

When all references to an object from within Erts are gone, the driver should
get a callback to notify it that all of the references are gone and the object
(should most likely) be freed.  This might be able to be handled much like
ErlDrvBinaries are handled today, only objects are attached to a specific port.

When the port is closed, all driver objects existing must be freed.  Perhaps
mini-references can be embedded in the object to act as sequence guards to ensure
that any left over object terms in Erlang are useless once that port has been closed.

I guess my brain got on this track because its somewhat similiar to ports and
process ids.  They are difficult to create for the sole reason that sane Erlang
applications should not attempt to create them, unless they are using open_port
or spawn.  Granted, pid_to_list exists for the sake of debugging, etc., but its
very "difficult" to create a pid or a port term, compared to creating and/or
accidentially modifying an int, binary or tuple, which would be common driver
reference types today.

After writing this suggestion, I'm wondering if its even worth wasting the
network bytes to transfer it to the mailing list, let alone actually implementing.
Might as well throw it out there for discussion though.

--
Shawn.

Why do I like Perl?  Because ``in accordance with Unix tradition Perl
gives you enough rope to hang yourself with.''

Why do I dislike Java? Because ``the class ROPE that should contain the
method HANG to do the hanging doesn't exist because there is too much
'security' built into the base language.''