<div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote">On Tue, Jun 26, 2012 at 10:19 AM, Greg Billock <span dir="ltr"><<a href="mailto:gbillock@google.com" target="_blank">gbillock@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been working with Michael Nordman on a problem related to Blob<br>
serialization. Currently, if we serialize a Blob, there's no<br>
notification to the BlobRegistry, so the serialized Blob will be<br>
garbage collected at an indeterminate time if the context in which it<br>
was created is closed. This lifetime scoping is spelled out clearly<br>
for Blob URLs created using the URL API. I see nothing in the spec<br>
imposing the same lifetime scoping on Blobs themselves, so I think it<br>
is an implementation flaw. To correctly handle this serialization<br>
case, however, the BlobRegistry needs to know when serialization and<br>
deserialization operations happen for Blob objects.<br>
<br>
I've created a patch that adds that logic and plumbs it through to the<br>
Chromium API. Webkit patch:<br>
<a href="https://bugs.webkit.org/show_bug.cgi?id=89921" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=89921</a> The corresponding<br>
Chromium-side patch is here: <a href="http://codereview.chromium.org/10662024/" target="_blank">http://codereview.chromium.org/10662024/</a><br>
<br>
<br>
The strategy I used is to create a new internal URL and use that for<br>
serialization:<br>
<br>
  KURL cloneURL = BlobURL::createInternalURL();<br>
  blobRegistry().didSerializeBlob(cloneURL, blob->url());<br>
  m_writer.writeBlob(cloneURL.string(), blob->type(), blob->size());<br>
  m_blobURLs.append(cloneURL.string());<br>
<br>
Then upon deserialization, there's a corresponding didDeserializeBlob call.<br>
<br>
There are a couple alternatives I considered. One is to not instrument<br>
the SerializedScriptValue this way, but require callers to use the<br>
blobURLs() accessor and do the right thing then. I'm more in favor of<br>
inserting this logic directly into serialization, since it removes an<br>
implementation gotcha and I think this more closely follows the spec.<br>
</blockquote><div><br></div><div>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.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Since the primary interaction with the BlobRegistry is via URL, I<br>
maintained that as well. The other is to use BlobData directly here.<br>
Michael is planning on doing some maintenance work to the ID system<br>
used internally anyway, and that may end up being the right path to<br>
take in that case.<br>
<br>
The open-ended implication of this change is that throwing away<br>
serialized values is now not acceptable -- they need to be checked for<br>
blob refs and then have some to-be-written code invoked to trigger the<br>
deref of the BlobData. We don't know where all that may be happening,<br>
currently, so it's still something of a science project. </blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We already<br>
have a SerializedScriptValue object we could interrogate upon<br>
destruction, but the whole point is that the wire format created there<br>
could show up anywhere, so we need to either restrict that ability and<br>
maintain object-level control, or trust callers of the serialized wire<br>
string accessor to handle them correctly. Neither is particularly<br>
exciting. Any better ideas?<br>
<br>
-Greg<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</blockquote></div><br></font></div>