Re: File API "oneTimeOnly" is too poorly defined

On 30.3.2012 15:21, Glenn Maynard wrote:
> 2012/3/29 Bronislav Klučka <Bronislav.Klucka@bauglir.com 
> <mailto:Bronislav.Klucka@bauglir.com>>
>
>     If I understand you, you find it problematic that by using weak
>     ref, URL would for some time reference actual Blob and other time
>     it would not?
>
>
> The problem is that the following code might or might not work, 
> depending on the behavior of the browser's GC:
>
> url = createObjectURL(blob);
> blob = null;
> setTimeout(function() { img.src = url; }, 0);
>
> If the timer executes before GC collects the blob, this works, because 
> the URL is still valid.  Otherwise, it fails, because--since the Blob 
> no longer exists--the URL is no longer valid.
>
> -- 
> Glenn Maynard
>

That should not be problematic; yes, GC may actually free that blob 
allocated memory later than that timeout function triggers, but there is 
explicit release of that blob (blob = null), so this must fail (memory 
might be allocated by blob data, but that variable should be out). But 
following may cause the same issue

var url = createObjectUrl(new Blob(['hello']));
setTimeout(function() { img.src = url; }, 0);

and even this in some aggressive GC implementation

img.src = createObjectUrl(new Blob(['hello']));
//since nothing references this blob, it could be destroyed right after 
function ends, but before assigning result,
// thou GC works most likely in some application idle state not to delay 
application process, theoretically this
// applies as well, since the functionality of GS is not specified = 
implementation specific

Thou I could live with such issue, I see the problem (from others 
programmers perspective and from specification perspective)... there's 
no light at the end of this tunnel...
Either carefully treat weak refs, or have one time ULRs with 
dereferencing and concurrency issues, or explicit URL release one might 
forget..

Brona

Received on Friday, 30 March 2012 16:07:57 UTC