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. 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. 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev