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

On Wed, Mar 7, 2012 at 1:00 PM, Charles Pritchard <chuck@jumis.com> wrote:
> On 3/7/12 12:34 PM, Kenneth Russell wrote:
>>
>> 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:
>>>
>>>> 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.
>
>
> Searching through the net tells me that this has been a rumor for years.

Regardless of rumors I have talked to multiple members of TC39 who
have clearly stated it is being incorporated into ES6 "Harmony".

> I agree with taking extreme care -- so let's isolate one more bit of
> information:
>
> Is ArrayBuffer being proposed for TC39 incorporation, or is it only the
> Typed Arrays? The idea here is to alter ArrayBuffer, an object which can be
> neutered via transfer map. It seems a waste to have to create a Worker to
> close down buffer views.

Both ArrayBuffer and the typed array views will be incorporated.

> Will TC39 have anything to say about the "neuter" concept and/or Web
> Messaging?

This is an excellent question and one which I've also posed to TC39. I
don't see how the language spec could reference these concepts. I'm
guessing that this is an area that TC39 hasn't yet figured out,
either.

> Again, I'm bringing this up for the same practical experience that
> Blob.close() was brought up. I do appreciate that read/write allocation is a
> separate semantic from write-once/read-many allocation.
>
> I certainly don't want to derail the introduction of Typed Array into TC39.
> I don't want to sit back for two years either, while the ArrayBuffer object
> is in limbo.

Understood and appreciated.

> If necessary, I'll do some of the nasty test work of creating a worker
> simply to destroy buffers, and report back on it.
> var worker = new Worker('trash.js');
> worker.postMessage(null,[bufferToClose]);
> worker.close();
> vs.
> bufferToClose.close();

I doubt that that will work. Garbage collection will still need to run
in the worker's JavaScript context in order for the transferred
ArrayBuffer to be cleaned up, and I doubt that happens eagerly upon
shutdown of the worker. Would be happy to be proven wrong.

If you prototype adding ArrayBuffer.close() in your open source
browser of choice and report back on significant efficiency
improvements in a real-world use case, that would be valuable
feedback.

-Ken

Received on Wednesday, 7 March 2012 21:39:33 UTC