> On Nov 20, 2014, at 4:51 PM, Maciej Stachowiak <m...@apple.com> wrote: > >> >> On Nov 20, 2014, at 9:26 AM, Alexey Proskuryakov <a...@webkit.org >> <mailto:a...@webkit.org>> wrote: >> >> >> 19 нояб. 2014 г., в 14:58, Alexey Proskuryakov <a...@webkit.org >> <mailto:a...@webkit.org>> написал(а): >> >>> These and related uses are all over the place - see also Vectors in >>> FormDataBuilder, data returned from FrameLoader::loadResourceSynchronously, >>> plug-in code that loads from network, SharedBuffer etc. >> >> Another way to say this is: we need to deal with large data arrays >> throughout loading code. We do not really need full size vectors in most >> other code - it's sort of OK for HTML parser or for image decoder to fail >> catastrophically when there is too much data fed to it. >> >> This is somewhat questionable design, but if we are going to stick to it, >> then magnitude checks should be centralized, not sprinkled throughout the >> code. We should not make this check explicitly when feeding a network >> resource to the parser, for example. >> >> A 64-bit API for Vector solves this nearly flawlessly. We do not perform the >> checks manually every time we use a Vector, Vector does them for us. >> >> Other options are: >> >> - uint64_t everywhere. This way, we'll solve practical problems with large >> resources once and for all. Also, this may prove to be necessary to solve >> even YouTube/Google Drive uploads, I do not know that yet. >> >> - size_t everywhere. Same effect on 64-bit platforms, while 32-bit ones will >> still be limited. I like this option, because it won't make us pay the >> memory and performance cost on old crippled 32-bit machines, which are >> unlikely to be used for manipulating huge volumes of data anyway. > > We probably want YouTube upload of large files to work on 32-bit machines. > Though presumably if you want to upload a file larger than the virtual > address space, you need to represent it in some way other than a Vector.
Thinking about this more - I think file sizes should probably be an off_t, not a size_t, so on 32-bit platforms some care must still be taken in the conversion between file sizes and vector sizes. In general, I like the idea of Vector having a size_t API and a choice of smaller or larger internal size. We might also want to change other containers with size-related interfaces to match. Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
