On Mon, Apr 21, 2025 at 6:21 PM J Decker <d3c...@gmail.com> wrote:
> You will have to wait for the JS stack to be idle for events to get
> dispatched... even promises are only dispatched from an idle state in the
> JS stack (where it has returned fully).
>
> You can call any JS functions in the initialization callback - but you
> cannot use the isolate or make a handle scope in not the right thread... so
> you have to wait for the uv_async_init'ed callback to be triggered before
> doing queued work.
>
> If this isn't sufficient and you really need parallel or injected
> execution - for node there's a worker-thread module ; but the eventual
> results have to be dispatched at the idle level still...
> https://github.com/laverdet/isolated-vm for example... (this is also a
> C++ thread that deals directly with allocating and managing isolates)
>
> you use `uv_async_init` once, which initialized a uv_async_t handle to be
> associated with a loop. You then use uv_async_send( handle ); which
> triggers dispatching to that routine; you will have to create a handle
> scope in that callback before doing JS functions. The handle can only be
> closed in the main thread also. The work can be queued to internal
> tracking, and when the async callback runs, it just checks for outstanding
> work, and calls appropriate JS callbacks.
>
By default - initializing handles for for uv_async_send to work - they add
a reference that keeps (node) running (I see this isn't actually a node
specific thread though)... you can async_unref( handle ) and that will keep
it schedulable, but not hold the process open. (may times like opening a
server socket, you'd want the process to not exit until that socket is
closed (which is probably never) but other situations might not be critical
enough to hold the process - my GUI interface has gone this way and the
window event dispatch don't actually keep the process open; but then I
ended up with a keep-alive setTimeout()... Just thought it might be useful
to note.
>
> On Mon, Apr 21, 2025 at 9:51 AM jmr <audrius.butkevic...@gmail.com> wrote:
>
>> Ok, seems that I CAN call js functions from within RequestInterrupt,
>> things seem to work.
>>
>> I guess I'm confused what this means in that case: "Registered |callback|
>> must not reenter interrupted Isolate."
>>
>>
>>
>> On Monday, 21 April 2025 at 17:41:21 UTC+1 jmr wrote:
>>
>>> I'm porting an application that is using SpiderMonkey for embedding, and
>>> I have a few questions.
>>>
>>> One of the things my application does is, it allows user (in javascript)
>>> to register for events:
>>>
>>> func handler(...) { {}
>>> registerEventHandler("evetName", handler);
>>>
>>> In C++, I then store these handlers to be called later once the event
>>> arrives.
>>>
>>> Once the event arrives (different thread than isolate is running on), I
>>> store it in a pending event list for the runtime (isolate), I then
>>> call JS_RequestInterruptCallback which interrupts the execution of the
>>> runtime (isolate), and drops into my C++ interrupt callback.
>>>
>>> From my C++ callback, I check for pending events, and call the user
>>> provided functions (re-entering the isolate) delivering the events, and
>>> resume execution to the user.
>>>
>>> Seems that with v8, I can get quite close to this, except
>>> isolate->RequestInterrupt does not allow re-entering the isolate/calling
>>> user code, making this not work.
>>>
>>> I tried using EnqueueMicrotask but seems those are never delivered
>>> automatically unless the script stops, or I call PerformMicrotaskCheckpoint
>>> (which then ends up on the wrong, calling thread)
>>>
>>> I tried posting a task to the platform
>>> (platform->GetForegroundTaskRunner(isolate)->PostTask), but given the
>>> script is long lived, I don't think this ever gets delivered.
>>>
>>> I tried using Locker(isolate) + Isolate::Scope(isolate)
>>> + isolate->GetCurrentContext() from the event thread, and then calling the
>>> callbacks, but this crashes non-deterministically, sometimes with "Invoke
>>> in DisallowJavascriptExecutionScope".
>>>
>>> Any guidance is appreciated.
>>> Thanks.
>>>
>>> --
>> --
>> v8-users mailing list
>> v8-users@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+unsubscr...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/v8-users/12e0876e-96b5-451f-8c88-11b4c4d8efd3n%40googlegroups.com
>> <https://groups.google.com/d/msgid/v8-users/12e0876e-96b5-451f-8c88-11b4c4d8efd3n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
--
v8-users mailing list
v8-users@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+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/v8-users/CAA2GJqUFfnj5ZKJ3vs_%2B1tAGAJPuuoGfEs38QtX-h4ek1NcMXw%40mail.gmail.com.
