Re: File API "oneTimeOnly" is too poorly defined

On Wed, Mar 28, 2012 at 4:36 PM, Glenn Maynard <glenn@zewt.org> wrote:
> Here's another proposal, which is an iteration of the previous.  It's based
> on the "microtask" concept, which is creeping up here and there but hasn't
> yet been properly defined.  The idea is that microtasks can be queued (call
> it "queue a microtask"), and the microtask queue is executed by the event
> loop as soon as the current task completes, so it executes as soon as the
> outermost task returns to the event loop.
>
> oneTimeOnly (a poor name in this proposal) would simply queue a microtask to
> revoke the URL.
>
> This is simpler, and answers a lot of questions.  It means you can use the
> URL as many times as you want synchronously, since it's not released until
> the script returns.  Any cases where the ordering may not be strictly
> defined (eg. the <video><video> case in
> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1265.html may
> be like this; I don't know how innerHTML works, exactly) are now defined:
> both <video> elements would get the object.
>
> It has another nice side-effect: it's much less prone to leaks.  For
> example, under previous approaches, the following code would leak the blob:
>
> function updateProgressMeter() { throw "obscure error"; }
> url = URL.createObjectURL(blob, {oneTimeOnly: true});
> updateProgressMeter();
> img.src = url; // never happens
>
> Since the URL is never actually used, the blob reference leaks.  You'd have
> to work around this with careful exception handling, which is precisely the
> sort of thing oneTimeOnly is supposed to avoid.  With this proposal, the URL
> would always be revoked when the script returns to the event loop, whether
> or not it was actually used.
>
> This would still require work in each URL-consuming spec, to define taking a
> reference to the underlying blob's data when it receives an object URL.  I
> think this is inherent to the feature.
>
> "oneTimeOnly" would be the wrong name with this approach; it should be
> something like "autoRelease".
>
> This has one drawback: it doesn't work nicely in long-running Workers, which
> may never return to the event loop at all.  I think that's probably an
> acceptable tradeoff.

This is an interesting idea for sure. It doesn't solve any of the
issues I brought up, so we still need to define when dereferencing
happens. But it does solve the problem of the URL leaking if it never
gets dereferenced, which is nice.

/ Jonas

Received on Thursday, 29 March 2012 00:50:03 UTC