On 2015/05/05 16:14:22, binji wrote:
On 2015/05/05 16:06:19, jochen wrote:
> If a SAB behaves like an AB of you don't use the correct atomics, we
could
> basically allow atomic operations on ABs as well - since they can't be
shared,
> nothing can go wrong.
True.
>
> It sounds like all we need is a bunch of constructors that create
regular
ABs
> and set a bit in addition that this AB can be shared.
Yes, that is how ncbray@'s prototype worked. But if a SAB is just an AB,
then
it
means that a SAB can be passed to APIs that expect ABs, which we don't
want.
Similarly, we don't want all the ArrayBuffer APIs to be available to SAB
(e.g.
ArrayBuffer.slice, ArrayBuffer.transfer, etc.)
Or are you thinking that SAB is a type that is only available to Blink,
not
v8?
Perhaps that is possible -- though I'm not sure how the v8 type <-> Blink
type
coercion works if the v8 type is shared between two Blink types.
I should also mention that we may need to store a mutex per SAB to handle
atomic
accesses on architectures that don't support 64-bit atomics. Similarly, we
may
need a data structure on the SAB to track futex waiters. There are other
possible implementations, but in general I think we will need some
additional
data structures on SAB types. We probably don't want to require those for
ArrayBuffers as well.
>
> Then we only need to check this bit when we need to decide whether to
neuter
or
> share the AB for postMessage.
https://codereview.chromium.org/1069883002/
--
--
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/d/optout.
