Seeking help with v8::Platform implementation

100 views
Skip to first unread message

Bit Cortex

unread,
Sep 18, 2015, 10:01:41 AM9/18/15
to v8-users
V8 experts,

I'm having trouble understanding the task scheduling requirements of the embedder's v8::Platform implementation. Some questions:

1. Is it a requirement that all foreground tasks for a given isolate be run on the same thread?
2. Must foreground tasks be run with the isolate lock held?
3. What are the embedder's responsibilities in terms of task cancellation or cleanup? How is cleanup supposed to work in general? For example, looking at the 4.6 source code, I see that V8 posts both foreground and background tasks that hold pointers to the isolate and/or its internals, such as the heap. What if the embedder disposes the isolate before a task is executed?

Thank you.

Ben Noordhuis

unread,
Sep 18, 2015, 1:22:45 PM9/18/15
to v8-u...@googlegroups.com
On Fri, Sep 18, 2015 at 4:01 PM, Bit Cortex <bitc...@gmail.com> wrote:
> V8 experts,
>
> I'm having trouble understanding the task scheduling requirements of the
> embedder's v8::Platform implementation. Some questions:
>
> 1. Is it a requirement that all foreground tasks for a given isolate be run
> on the same thread?

I don't think that's a hard requirement, but...

> 2. Must foreground tasks be run with the isolate lock held?

...yes, you have to hold the lock.

> 3. What are the embedder's responsibilities in terms of task cancellation or
> cleanup? How is cleanup supposed to work in general? For example, looking at
> the 4.6 source code, I see that V8 posts both foreground and background
> tasks that hold pointers to the isolate and/or its internals, such as the
> heap. What if the embedder disposes the isolate before a task is executed?

I'm not 100% sure about this one but I think it works like this:

1. Only foreground threads are cancellable.
2. You need to hold the isolate lock when running foreground tasks.
3. The only place where threads are cancelled is in Isolate::Dispose().
4. Ergo, there should be no room for race conditions -
Isolate::Dispose() cleans up after itself.

For background tasks, just flush your background task queue. I'd
probably opt for flushing both queues before you tear down the
isolate, just to be on the safe side.

Bit Cortex

unread,
Sep 21, 2015, 11:45:29 AM9/21/15
to v8-users
Ben, thanks for your response. Follow-up questions below:

> 2. Must foreground tasks be run with the isolate lock held?

...yes, you have to hold the lock.

Hmm, I just noticed that v8::platform::DefaultPlatform doesn't acquire the lock to run foreground tasks. On the other hand, the V8 samples never run scripts and foreground tasks concurrently, so it's unclear whether doing so is safe. Also, if holding the lock is a practical requirement, then how would you deal with long-running scripts? Would it make sense to implement CallOnForegroundThread() via v8::Isolate::RequestInterrupt()?
 
For background tasks, just flush your background task queue.  I'd
probably opt for flushing both queues before you tear down the
isolate, just to be on the safe side.

Currently I don't have a background task queue; my implementation of CallOnBackgroundThread() simply posts a work item to the OS thread pool, but looking at what the work items actually do, I don't see how that can be safe. In any case, when you say "flush your background task queue", do you mean wait until all background tasks are finished executing? That seems like it could be a long wait if multiple isolates are concurrently posting new background tasks.

Thanks.

Jochen Eisinger

unread,
Sep 22, 2015, 3:01:28 AM9/22/15
to v8-users
Currently, the foreground tasks can run wherever the embedder wants to run them, but in the future, we might require that it's safe to access the given isolate from foreground tasks.

Background tasks can run wherever the embedder likes, and they will take care themselves to use locks etc.. to access the isolate. Some of the tasks will either do nothing if the isolate was already destroyed by the time they run, for other tasks, the isolate will block the current thread when you try to destroy it until all background tasks where executed.

In Chrome on Windows, we also post background tasks to the OS thread pool.

--
--
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Bit Cortex

unread,
Sep 25, 2015, 7:17:18 AM9/25/15
to v8-users
Jochen, thanks for your help. Just hoping to get one more clarification:


On Tuesday, September 22, 2015 at 3:01:28 AM UTC-4, Jochen Eisinger wrote:
Currently, the foreground tasks can run wherever the embedder wants to run them, but in the future, we might require that it's safe to access the given isolate from foreground tasks.

When you say that it must be "safe to access the given isolate from foreground tasks", do you mean that the embedder must not run foreground tasks concurrently with script execution? A related question: Do you know whether it's safe (or prudent, or a requirement) for the embedder to hold the isolate lock while running foreground tasks?

Thanks again.
Reply all
Reply to author
Forward
0 new messages