Re: [FileAPI] Deterministic release of Blob proposal

After a brief internal discussion, we like the idea over in Chrome-land.
Let's make sure that we carefully spec out the edge cases, though.
See below for some.

On Fri, Mar 2, 2012 at 4:54 PM, Feras Moussa <ferasm@microsoft.com> wrote:
> At TPAC we discussed the ability to deterministically close blobs with a few
>
> others.
>
>
>
> As we’ve discussed in the createObjectURL thread[1], a Blob may represent
>
> an expensive resource (eg. expensive in terms of memory, battery, or disk
>
> space). At present there is no way for an application to deterministically
>
> release the resource backing the Blob. Instead, an application must rely on
>
> the resource being cleaned up through a non-deterministic garbage collector
>
> once all references have been released. We have found that not having a way
>
> to deterministically release the resource causes a performance impact for a
>
> certain class of applications, and is especially important for mobile
> applications
>
> or devices with more limited resources.
>
>
>
> In particular, we’ve seen this become a problem for media intensive
> applications
>
> which interact with a large number of expensive blobs. For example, a
> gallery
>
> application may want to cycle through displaying many large images
> downloaded
>
> through websockets, and without a deterministic way to immediately release
>
> the reference to each image Blob, can easily begin to consume vast amounts
> of
>
> resources before the garbage collector is executed.
>
>
>
> To address this issue, we propose that a close method be added to the Blob
>
> interface.
>
> When called, the close method should release the underlying resource of the
>
> Blob, and future operations on the Blob will return a new error, a
> ClosedError.
>
> This allows an application to signal when it's finished using the Blob.
>
>
>
> To support this change, the following changes in the File API spec are
> needed:
>
>
>
> * In section 6 (The Blob Interface)
>
>   - Addition of a close method. When called, the close method releases the
>
> underlying resource of the Blob. Close renders the blob invalid, and further
>
> operations such as URL.createObjectURL or the FileReader read methods on
>
> the closed blob will fail and return a ClosedError.  If there are any
> non-revoked
>
> URLs to the Blob, these URLs will continue to resolve until they have been
>
> revoked.
>
>   - For the slice method, state that the returned Blob is a new Blob with
> its own
>
> lifetime semantics – calling close on the new Blob is independent of calling
> close
>
> on the original Blob.
>
>
>
> *In section 8 (The FIleReader Interface)
>
> - State the FileReader reads directly over the given Blob, and not a copy
> with
>
> an independent lifetime.
>
>
>
> * In section 10 (Errors and Exceptions)
>
> - Addition of a ClosedError. If the File or Blob has had the close method
> called,
>
> then for asynchronous read methods the error attribute MUST return a
>
> “ClosedError” DOMError and synchronous read methods MUST throw a
>
> ClosedError exception.
>
>
>
> * In section 11.8 (Creating and Revoking a Blob URI)
>
> - For createObjectURL – If this method is called with a closed Blob
> argument,
>
> then user agents must throw a ClosedError exception.
>
>
>
> Similarly to how slice() clones the initial Blob to return one with its own
>
> independent lifetime, the same notion will be needed in other APIs which
>
> conceptually clone the data – namely FormData, any place the Structured
> Clone
>
> Algorithm is used, and BlobBuilder.

What about:

	XHR.send(blob);
	blob.close();

or

	iframe.src = createObjectURL(blob);
	blob.close();

In the second example, if we say that the iframe does copy the blob,
does that mean that closing the blob doesn't automatically revoke the
URL, since it points at the new copy?  Or does it point at the old
copy and fail?

> Similarly to how FileReader must act directly on the Blob’s data, the same
> notion
>
> will be needed in other APIs which must act on the data - namely XHR.send
> and
>
> WebSocket. These APIs will need to throw an error if called on a Blob that
> was
>
> closed and the resources are released.
>
>
>
> We’ve recently implemented this in experimental builds and have seen
> measurable
>
> performance improvements.
>
>
>
> The feedback we heard from our discussions with others at TPAC regarding our
>
> proposal to add a close() method to the Blob interface was that objects in
> the web
>
> platform potentially backed by expensive resources should have a
> deterministic
>
> way to be released.
>
>
>
> Thanks,
>
> Feras
>
>
>
> [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1499.html

Received on Tuesday, 6 March 2012 20:30:17 UTC