Ah that sounds more like the proper way to do it :)
I've not tried interrupts yet, so I'm no use here :)
On Wednesday, 14 November 2018 17:45:03 UTC, Konrad Piascik wrote:
>
> I have attached to node with the program executing in the middle of a
> while/busy loop.
> I think I found what node is
I have attached to node with the program executing in the middle of a
while/busy loop.
I think I found what node is doing.
https://github.com/v8/v8/blob/96a039aab14b71069e88c4c04543e6bc9514a0d6/include/v8.h#L7969
void v8::Isolate::RequestInterrupt(InterruptCallback callback, void* data);
This
Going off topic now, but can you attach & break into node.js whilst it's in
a big blocking function?
Or can you only break if you've previously attached? (I've only done light,
very-async stuff in node)
In long-running funcs (well, accidental massive loops) in chrome I find I
struggle to
Yeah I can't make any assumptions or impose any requirements about what the
javascript to be executed will look like.
It must be possible since Node.js already does this for long running
JavaScript.
Thanks for the suggestions and quick responses
-Konrad
On Wednesday, November 14, 2018 at
The only way I could interrupt long runs of javascript, assuming you can't
break it yourself into asynchronous code (via promises/await, this is the
nicest approach IMO me), is adding a yield function to let the event loop
run (I have other multithread-y reasons for this too, but letting
Hi @soylentgraham,
I'm trying to replicate what you're doing as well but am running into some
other problems. The most notable of which is that my websocket is on a
different thread than my isolate creation.
I see from your solution that you're adding the frontend messages to a
queue and
YetAnotherUpdate
After some more digging, I found the issue I have is identified node and
chromium too...
https://github.com/nodejs/node/commit/b1e26128f317a6f5a5808a0a727e98f80f088b84
So, it looks like the default v8 [platform] isn't chrome-dev-tools
compatible.
Ibon's case worked as it has
So the core of my issue at the moment, is this assert (UNIMPLEMENTED)
void DefaultWorkerThreadsTaskRunner::PostDelayedTask(std::unique_ptr
task,
double
delay_in_seconds) {
base::LockGuard guard(_);
if (terminated_) return;
if
For any future readers;
I went back to trying to build a debug v8 set of libs (wouldnt compile
before, added is_component_build=false which I think fixed that)
Built with latest master (4544e18b0c3845a9fca422cf0903df4803343cf1)
Which forced me to correct a few uses of deprecated functions,
With a lot of back & forth help from Ibon/hyperandroid, we've got a bit
further in working out which things are good, and which are bad.
Feels like we're close, but things are still unstable, and a bit
unresponsive.
I can kinda break into the code (which only shows *this *in sources)
Still get
I get the same sequence of messages, and I don't need to implement anything
about them to have a fully functional debugging session between embedded v8
(android) and chrome dev tools.
El lunes, 27 de agosto de 2018, 14:49:37 (UTC+2), Graham Reeves escribió:
>
> Through various sources (ie,
11 matches
Mail list logo
