SungchulCho / v8-juice

Automatically exported from code.google.com/p/v8-juice
Other
0 stars 0 forks source link

Feature request: persistent binding of a JS callable to a native callback #13

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
To quote Rob Tsuk:

--------------------
My curl library is set up to take a callback that receives the results of
the curl "get" call as a string. The native layer needs to keep the
reference to the callback function alive until it calls it, otherwise if
the function is an anonymous function (say something created with
Prototype's bind) it could be garbage collected before the curl callback is
called.

The vague notion I had is some C++ wrapper object that took care of both
the function call binding and keeping the persistent reference to JS
function object. The wrapper would give you a "call" member function that
would have the right C++ signature, and as long as this wrapper is alive
the function object would be kept alive with a persistent reference.
--------------------

The sqlite3 plugin could also make use of such a feature for binding custom
SQL functions. Historically, i've had problems with the JS callable getting
GC'd by the time the client actually calls it, and such a
wrapper/class/helper could assist in that.

Reminder to self: it seems that the only important thing to remember for
implementing this is to use Persistent<Function> to keep the handle alive.
That said, i've seen many cases involving bound callbacks where the Context
is Null when the callback is made, causing a crash the moment it is called.
(i can't for the life of me remember in which plugin i experimented with
that, but finding that code may be useful here.)

In theory such a wrapper would simply need to encapsulate the JS callable
(Persistent<Function>), the native callback function/functor, and one of
the (generated) FunctionForwarder() template specializations (e.g. see
forwarding-FunctorForwarder.h). It would probably be useful to based this
on top of, or model it like, a more generic functor framework (in the style
of Alexandrescu's Loki functors).

Original issue reported on code.google.com by sgbeal@googlemail.com on 11 Oct 2009 at 7:40

GoogleCodeExporter commented 8 years ago

Original comment by sgbeal@googlemail.com on 15 Oct 2009 at 10:24

GoogleCodeExporter commented 8 years ago
i _think_ this can be done by creating a thin wrapper around the 
FunctionForwarder
API, which simply adds the JS handle. To ensure proper cleanup in the face of 
copying
the Persistento Handle, though, i _think_ we would need to add reference 
counting to
be sure we only Dispose() the Persistent Handle one time. i think.

Original comment by sgbeal@googlemail.com on 16 Oct 2009 at 2:39

GoogleCodeExporter commented 8 years ago

Original comment by sgbeal@googlemail.com on 4 Jul 2011 at 9:57