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

On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchard <chuck@jumis.com> wrote:
>
> 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.

It's certainly a matter of opinion -- but while it's only the addition
of one method, it changes typed arrays' semantics to be much closer to
manual memory allocation than they currently are. It would be a
further divergence in behavior from ordinary ECMAScript arrays.

The TC39 working group, I have heard, is incorporating typed arrays
into the language specification, and for this reason I believe extreme
care is warranted when adding more functionality to the typed array
spec. The spec can certainly move forward, but personally I'd like to
check with TC39 on semantic changes like this one. That's the
rationale behind my statement above about preferring not to add this
method at this time.

-Ken


> 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:35:29 UTC