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

On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard <glenn@zewt.org> wrote:
> 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).

Closing an object, and neutering it because it was transferred to a
different owner, are different concepts. It's already been
demonstrated that Blobs, being read-only, do not need to be
transferred in order to send them efficiently from one owner to
another. It's also been demonstrated that Blobs can be resource
intensive and that an explicit closing mechanism is needed.

I believe that we should fix the immediate problem and add a close()
method to Blob. I'm not in favor of adding a similar method to
ArrayBuffer at this time and therefore not to Transferable. There is a
high-level goal to keep the typed array specification as minimal as
possible, and having Transferable support leak in to the public
methods of the interfaces contradicts that goal.

-Ken

Received on Wednesday, 7 March 2012 19:39:31 UTC