It could be an issue that is already solved, given that the v8 version in
Node is usually set at release time. Particularly if you are using an older
version of node.
You might want to try with node 10 as well, which was recently released.
On Saturday, April 7, 2018 at 12:48:51 AM UTC+2, J Decke
I'd suggest you poke around https://v8.dev/docs. If you are interested in
how builtins are implemented, read https://v8.dev/docs/csa-builtins and
about Torque: https://v8.dev/docs/torque.
There are also a lot of talks available which explain overall concepts -
you can watch them and then try to
Can you delay the printing so that GDB has a chance to start up before the
console.log()? Getting a stack trace out of GDB would really be the best
way to debug from here.
On Tuesday, January 15, 2019 at 3:26:58 AM UTC+1, Paul Spencer wrote:
>
> Hi, first post here and this may be the wrong spot
Yep, try/catch is supported by the optimizing compiler now. Use it to your
heart's content :)
On Wednesday, February 20, 2019 at 2:41:20 AM UTC+1, Peter Wong wrote:
>
> I'm fairly certain this no longer the case, and you stop avoiding
> try/catch. https://github.com/tildeio/rsvp.js/pull/539
--
I don't know of a way to do that. But you can use the sampling CPU profiler
if you only want a statistical estimate and don't care about the exact
number. You can use that through Chrome DevTools
On Tuesday, February 26, 2019 at 10:36:27 PM UTC+1, Harold Camacho wrote:
>
> Hi
>
> I wanted some h
I'm working on implementing
DefaultWorkerThreadsTaskRunner::PostDelayedTask() right
now: https://chromium-review.googlesource.com/c/v8/v8/+/1521114
Also I'm not sure why you are hitting this - where does the call to
PostDelayedTask() with a non-zero delay come from?
On Friday, February 22, 201
You can link to the question and we can try to answer there. We try to keep
an eye on questions tagged with v8
On Thursday, April 11, 2019 at 7:27:16 AM UTC-4, DaManuell wrote:
>
> Or should I just copy/paste here the entire question?
>
--
--
v8-users mailing list
v8-users@googlegroups.com
htt
Yeah I don't think this is designed to be thread-safe. For example, we end
up calling ProfilerEventsProcessor::AddCurrentStack()
which creates a StackFrameIterator from the isolate. To do this it
calls isolate->thread_local_top(). The main thread will still be modifying
ThreadLocalTop while the 2
On Wednesday, May 15, 2019 at 9:09:18 PM UTC+2, Ledion Bitincka wrote:
>
> Thanks!
>
> > While I understand that this is tempting, please be aware that only one
> thread may be active in one Isolate at any given time.
> I was hoping that there could be multiple threads that had "read-only"
> acc
If you block the main thread at a safe time (e.g. not during GC) then you
can probably access heap objects from your other threads without handles as
long as you do your own synchronization between the background threads.
Not sure how concurrent marking threads from the GC will feel about that
t
10 matches
Mail list logo
