Convert Value* back to Local<Value>

[J Decker]

I have this process that wants to take the result of a callback and then pass that as the object for the next callback invokation...

(truncated; argc is missing for instance; mostly I'm just intested in result, and the arg back in )

void f( uintptr_t psv )

{

Local<Value> *argv = new Local<Value>[argc+1];

Local<Object> recv = ((Value*)psv)->ToObject();

Local<Function> cb = rule->handler.Get( config->isolate );

Local<Value> result = cb->Call( recv, argc, argv );

// figured I can get the result this way, and keep it ?

uintptr_t objResult = (uintptr_t)*result;

result.Clear();

return objResult; // this gets passed to next f(psv)

}

on the javascript side the callback might be something like

config.add( "format %d", function( arg ) {

   this.format_arg = arg;

   return this; 

}

so any time the string "format ###" is found, the callback is triggered with ### formatted as an integer argument (for instance )

most usages the callbacks will all be performed before returning back to the orignal javascript caller, but, it can be that the javascript is adding streaming data to the text processor iteritively so there may be a long time between one call to f() and the next... would the 'result' be subject to garbage collection when it's not in a Local<> or Persistent<>  ?

[J Decker]

I would have a very last handler....

static uintptr_t CPROC releaseArg( uintptr_t lastArg ) {

Local<Object> deleteMe = ( (Value*)lastArg )->ToObject();

return 0;

}

which should release it when the stream is done.... so it shouldn't leak if it's not collected...

[Ben Noordhuis]

On Fri, Dec 15, 2017 at 7:17 AM, J Decker <d3c...@gmail.com> wrote:
> most usages the callbacks will all be performed before returning back to the
> orignal javascript caller, but, it can be that the javascript is adding
> streaming data to the text processor iteritively so there may be a long time
> between one call to f() and the next... would the 'result' be subject to
> garbage collection when it's not in a Local<> or Persistent<> ?

Yes, and keep in mind a Local won't safe you if its HandleScope is
destroyed in the interim - it needs to be a Persistent in that case.

[J Decker]

to clarify; you're saying it will be potentially garbage collected unless in a persistent?

and with the result.Clear(); it's no longer in the local so that destruction wouldn't matter.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Noordhuis]

On Mon, Dec 18, 2017 at 10:11 PM, J Decker <d3c...@gmail.com> wrote:
>
>
> On Mon, Dec 18, 2017 at 2:43 PM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
>>
>> On Fri, Dec 15, 2017 at 7:17 AM, J Decker <d3c...@gmail.com> wrote:
>> > most usages the callbacks will all be performed before returning back to
>> > the
>> > orignal javascript caller, but, it can be that the javascript is adding
>> > streaming data to the text processor iteritively so there may be a long
>> > time
>> > between one call to f() and the next... would the 'result' be subject to
>> > garbage collection when it's not in a Local<> or Persistent<> ?
>>
>> Yes, and keep in mind a Local won't safe you if its HandleScope is
>> destroyed in the interim - it needs to be a Persistent in that case.
>
> to clarify; you're saying it will be potentially garbage collected unless in
> a persistent?

Yes, correct.

> and with the result.Clear(); it's no longer in the local so that destruction
> wouldn't matter.

That's a misunderstanding. Clear() only clears the Local, not the
HandleScope slot it points to that contains the actual Value.