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

On Mar 7, 2012, at 11:38 AM, Kenneth Russell <kbr@google.com> wrote:

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

I think there's broad enough consensus amongst vendors to table the discussion about adding close to Transferable.

Would you please let me know why ypu believe ArrayBuffer should not have a close method?

I would like some clarity here. The Typed Array spec would not be cluttered by the addition of a simple close method.

I work much more with ArrayBuffer than Blob. I suspect others will too as they progress with more advanced and resource intensive applications.

What is the use-case distinction between close of immutable blob and close of a mutable buffer?

-Charles

Received on Wednesday, 7 March 2012 20:02:50 UTC