[webkit-dev] Notifications for Blob serialization/deserialization

[Joshua Bell]

On Tue, Jun 26, 2012 at 10:19 AM, Greg Billock <gbillock at google.com> wrote:

> I've been working with Michael Nordman on a problem related to Blob
> serialization. Currently, if we serialize a Blob, there's no
> notification to the BlobRegistry, so the serialized Blob will be
> garbage collected at an indeterminate time if the context in which it
> was created is closed. This lifetime scoping is spelled out clearly
> for Blob URLs created using the URL API. I see nothing in the spec
> imposing the same lifetime scoping on Blobs themselves, so I think it
> is an implementation flaw. To correctly handle this serialization
> case, however, the BlobRegistry needs to know when serialization and
> deserialization operations happen for Blob objects.
>
> I've created a patch that adds that logic and plumbs it through to the
> Chromium API. Webkit patch:
> https://bugs.webkit.org/show_bug.cgi?id=89921 The corresponding
> Chromium-side patch is here: http://codereview.chromium.org/10662024/
>
>
> The strategy I used is to create a new internal URL and use that for
> serialization:
>
>  KURL cloneURL = BlobURL::createInternalURL();
>  blobRegistry().didSerializeBlob(cloneURL, blob->url());
>  m_writer.writeBlob(cloneURL.string(), blob->type(), blob->size());
>  m_blobURLs.append(cloneURL.string());
>
> Then upon deserialization, there's a corresponding didDeserializeBlob call.
>
> There are a couple alternatives I considered. One is to not instrument
> the SerializedScriptValue this way, but require callers to use the
> blobURLs() accessor and do the right thing then. I'm more in favor of
> inserting this logic directly into serialization, since it removes an
> implementation gotcha and I think this more closely follows the spec.
>

The blobURLs() accessor was put in as a stop-gap to let us detect
Blobs-in-SSVs and fail early when the full plumbing was missing. Don't read
too much into its presence. (In practical terms, its current use could be
replaced by a "does this SSV contain a Blob?" flag, but at the time
exposing the list seemed like it might be useful.)


> Since the primary interaction with the BlobRegistry is via URL, I
> maintained that as well. The other is to use BlobData directly here.
> Michael is planning on doing some maintenance work to the ID system
> used internally anyway, and that may end up being the right path to
> take in that case.
>
> The open-ended implication of this change is that throwing away
> serialized values is now not acceptable -- they need to be checked for
> blob refs and then have some to-be-written code invoked to trigger the
> deref of the BlobData. We don't know where all that may be happening,
> currently, so it's still something of a science project.


Please coordinate with ericu@ (I'm sure you're already in contact) who is
looking at how to enable Blob support for IndexedDB. It's going to be one
of the more exciting cases, which  includes SSV data flowing across process
boundaries (in the Chromium port), storage to disk, and deletion
operations occurring in processes that do not have script contexts
available.


> We already
> have a SerializedScriptValue object we could interrogate upon
> destruction, but the whole point is that the wire format created there
> could show up anywhere, so we need to either restrict that ability and
> maintain object-level control, or trust callers of the serialized wire
> string accessor to handle them correctly. Neither is particularly
> exciting. Any better ideas?
>
> -Greg
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120626/2161dc8d/attachment.html>