Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman <michaeln@google.com> wrote:

> > You can always call close() yourself, but Blob.close() should use the
> > "neuter" mechanism already there, not make up a new one.
>
> Blobs aren't transferable, there is no existing mechanism that applies
> to them. Adding a blob.close() method is independent of making blob's
> transferable, the former is not prerequisite on the latter.
>

There is an existing mechanism for closing objects.  It's called
"neutering".  Blob.close should use the same terminology, whether or not
the object is a Transferable.

On Tue, Mar 6, 2012 at 4:25 PM, Kenneth Russell <kbr@google.com> wrote:

> I would be hesitant to impose a close() method on all future
> Transferable types.


Why?  All Transferable types must define how to neuter objects; all close()
does is trigger it.

I don't think adding one to ArrayBuffer would be a
> bad idea but I think that ideally it wouldn't be necessary. On memory
> constrained devices, it would still be more efficient to re-use large
> ArrayBuffers rather than close them and allocate new ones.
>

That's often not possible, when the ArrayBuffer is returned to you from an
API (eg. XHR2).

 This sounds like a good idea. As you pointed out offline, a key
> difference between Blobs and ArrayBuffers is that Blobs are always
> immutable. It isn't necessary to define Transferable semantics for
> Blobs in order to post them efficiently, but it was essential for
> ArrayBuffers.
>

No new semantics need to be defined; the semantics of Transferable are
defined by postMessage and are the same for all transferable objects.
That's already done.  The only thing that needs to be defined is how to
neuter an object, which is what Blob.close() has to define anyway.

Using Transferable for Blob will allow Blobs, ArrayBuffers, and any future
large, structured clonable objects to all be released with the same
mechanisms: either pass them in the "transfer" argument to a postMessage
call, or use the consistent, identical close() method inherited from
Transferable.  This allows developers to think of the transfer list as a
list of objects which won't be needed after the postMessage call.  It
doesn't matter that the underlying optimizations are different; the visible
side-effects are identical (the object can no longer be accessed).

-- 
Glenn Maynard