Re: [FileAPI] Deterministic release of Blob proposal

On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa <ferasm@microsoft.com> wrote:

> 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.
>

This is exactly like the "neuter" concept, defined at
http://dev.w3.org/html5/spec/common-dom-interfaces.html#transferable-objects.
I recommend using it.  Make Blob a Transferable, and have close() neuter
the object.  The rest of this wouldn't change much, except you'd say "if
the object has been neutered" (or "has the neutered flag set", or however
it's defined) instead of "if the close method has been called".

Originally, I think it was assumed that Blobs don't need to be
Transferable, because they're immutable, which means you don't
(necessarily) need to make a copy when transferring them between threads.
That was only considering the cost of copying the Blob, though, not the
costs of delayed GC that you're talking about here, so I think transferable
Blobs do make sense.

Also, the close() method should probably go on Transferable (with a name
less likely to clash, eg. "neuter"), instead of as a one-off on Blob.  If
it's useful for Blob, it's probably useful for ArrayBuffer and all other
future Transferables as well.

-- 
Glenn Maynard