Re: Mutability of CryptoOperationData

29 окт. 2013 г., в 12:17, Ryan Sleevi <sleevi@google.com> написал(а):

> Spec wise, I think the goal should be to permit any number of possible internal implementations, provided the external behaviour remains consistent. The 'expected' external behaviour is that the operation acts upon the data present in the CryptoOperationData at the time of the call. This would be specified by describing the normative-equivalent operation as taking a copy of all the data during the call - eg: by invoking Structured Clone and then freezing the structured clone (but *not* neutering or freezing the original). Implementations could then implement COW w/o violating that normative guarantee.

I just got strong feedback from our JavaScript team. Sounds like the practical choices are:
- freeze the input buffers;
- copy the data eagerly (bad for WebCrypto performance, but won't kill performance of other code that uses typed arrays, like WebGL);
- make the algorithms run synchronously on the main thread.


It would not be practical to implement copy-on-write for array buffers.  Array buffers are meant to be used as arrays for JavaScript code.  If we added copy-on-write then every single store operation into every single array would have to do a check to see if it should invoke a copying operation.  This gets really horrific very quickly and would lead to a dramatic performance regression for JavaScript.

This regression wouldn't just manifest for our JS engine but also for any other JS engine that also implemented copy-on-write for crypto.

- WBR, Alexey Proskuryakov