On 2013/09/05 17:28:37, Sven Panne wrote:
On 2013/09/05 15:36:39, rmcilroy wrote:
> Thanks Sven. I've had to slightly change the API to take a pointer to a
boolean
> so that the setResourceConstraints will not re-set
is_memory_constrained if
the
> ResourceConstraint being passed didn't have a call to
set_memory_constrained
> (e.g., treat the value as either do-nothing, set to true or set to
false).
I
> had to do this because this will be called by both Chrome code and Blink
code,
> so I need to have a "do nothing" option to avoid Chrome setting it to
true,
and
> blink accidentally setting back to the default of false.
>
> PTAL. If you are happy with it could you please land it for me (I'm
not a
V8
> committer yet).
NOT LGTM. The plan regarding Isolates and ResourceConstraints is that
there
will
be exactly one way to create an Isolate (no default Isolate anymore) via
some
constructor or factory method, and this constructor/factory will get
optional
ResourceConstraints (or something similar). Therefore there should be
exactly
*one* place to construct ResourceConstraints, and you should basically
view
them
as immutable. Put another way: ResourceConstraints are just additional
arguments
to the Isolate constructor/factory, i.e. it's an argument object.
Perhaps I misunderstood things, so we should clarify this tomorrow or next
week,
but giving out a pointer to parts of that argument object seems
fundamentally
wrong.
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?
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.
