On 2013/09/05 18:29:59, rmcilroy wrote:
Sorry, I think we are misunderstanding. There is still only a single
ResourceConstraint (which is in-effect immutable and is treated as an
argument
object). There is no intention that if the embedder changes the
ResourceConstraint object after they have called setResourceConstraints,
that
this would have any effect. It is only that both Blink and Chrome will
create
their own ResourceConstraint object (setting different settings on this
ResourceConstraint), and call setResourceConstraints on them
independently. I
changed the bool to a bool* in order to have a NULL (i.e., unset) as well
as
true/false for the constraint, like the other constraints do (e.g.,
having '0'
as being unset). I originally used an enum for this instead of making it
a
pointer, but thought it was a bit clunky, but can go back to that model
if you
don't like this being a pointer?
Using an enum is one possibility, but I think we could make things much
cleaner
when we move our internal Maybe template into the v8.h header and let the
ResourceConstraints getter return a Maybe<foo> instead of foo.
I had a look at the Chrome/Blink code, and I am not sure where one would
set the
ResourceConstraints for the main thread (workers are easy, they have an
explicit
Isolate::New()). The current API is extremely fragile, because you have to
call
SetResourceConstaints very, very early. Adding Dan...
https://codereview.chromium.org/23464022/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
