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

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

> On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan
> <aranganathan@mozilla.com> wrote:
>> Ken,
>> 
>>> I'm not sure that adding close() to Transferable is a good idea. Not
>>> all Transferable types may want to support that explicit operation.
>>> What about adding close() to Blob, and having the neutering operation
>>> on Blob be defined to call close() on it?
>> 
>> 
>> Specifically, you think this is not something ArrayBuffer should inherit?  If it's also a bad idea for MessagePort, then those are really our only two use cases of Transferable right now.  I'm happy to create something like a close() on Blob.
> 
> MessagePort already defines a close() operation, so there's really no
> question of whether its presence is a good or bad idea there. A
> close() operation seems necessary in networking style APIs.
> 
> I would be hesitant to impose a close() method on all future
> Transferable types. 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.


By definition, Transferable objects can be neutered; we're talking about an explicit method for it. After that, it's up to implementers.

I prefer .close to .release. 

An ArrayBuffer using 12megs of ram is something I want to release ASAP on mobile.

.close would still allow for the optimization you're implying in memory mapping.





> 
> 
> On Tue, Mar 6, 2012 at 1:34 PM, Michael Nordman <michaeln@google.com> wrote:
>> Sounds like there's a good case for an explicit blob.close() method
>> independent of 'transferable'. Separately defining blobs to be
>> transferrable feels like an unneeded complexity. A caller wishing to
>> neuter after sending can explicit call .close() rather than relying on
>> more obscure artifacts of having also put the 'blob' in a
>> 'transferrable' array.
> 
> 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.
> 

Making Blob a Transferable may simplify the structured clone algorithm; Blob an File would no longer be explicitly listed. Adding close to Transferable would simplify three different objects -- ArrayBuffer, MessagePort and Blob. In theory anyway.

While Blob doesn't need the transfer map optimization, it may be helpful in the context of web intents postMessage as it would release the Blob references from one window, possibly making GC a little easier. That's just a guess... But this thread is about enhancing the process. Seems reasonable that this would be a side effect.

File.close() may have implementation side effects, such as releasing read locks on underlying files.

-Charles

Received on Tuesday, 6 March 2012 22:52:22 UTC