>
> assume you're asking this in the context
> of VS Code
>
Yes, this would apply to any process in VS Code, including the renderer.
On Monday, March 5, 2018 at 6:29:13 AM UTC+1, Ben Noordhuis wrote:
>
> On Fri, Mar 2, 2018 at 5:55 PM, Benjamin Pasero
> wrote:
> >
On Wed, Feb 28, 2018 at 6:19 AM, A.M. wrote:
>> The answer is "it depends." If you're not going to call into V8 at
>> all it's _probably_ safe but most V8 APIs can kick off a GC run. Call
>> `v8::Isolate::Dispose()` first to be safe.
>
> Is there a best-practices way to
On Wed, Feb 28, 2018 at 6:05 AM, A.M. wrote:
> On Tuesday, 27 February 2018 19:21:03 UTC-5, Ben Noordhuis wrote:
>>
>> IIRC, it's a two-pass system: first pass should reset the persistent
>> handle, second pass is the real finalizer. Preempting the question of
>> why it works
On Fri, Mar 2, 2018 at 5:55 PM, Benjamin Pasero
wrote:
> Hi,
>
> I am wondering what the performance impact would be if I would change
> Error.stackTraceLimit [1] to a high value (e.g. 1000?). The default of just
> 10 stack frames is little when the error bubbles
On Sat, Mar 3, 2018 at 9:17 AM Koray wrote:
> Hello Jakob,
>
> Thank you for your response. I will make sure to design my application
> accordingly.
>
> My next question would be, does v8 optimize according to new prototype
> changes after a while?
Yes.
> Or should I
> I still don't understand what the point of this call is under any
circumstances when you can get the internal fields out of your object
The first pass weak handle callback can call only a couple v8 functions
(i.e. reset the handle and set up the second-pass callback) and is not
supposed to