W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: onEnded and connections

From: K. Gadd <kg@luminance.org>
Date: Wed, 4 Sep 2013 22:16:41 -0700
Message-ID: <CAPJwq3UGOyukOyoRdwzPbJ3EbDU8mSEcMwoqe0kiFtQgjXd=7Q@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Raymond Toy <rtoy@google.com>, Chris Wilson <cwilso@google.com>, "public-audio@w3.org" <public-audio@w3.org>
How is this resolved to prevent observability of GC? Any source node that
has been started lives until it stops playing, even if it is not connected
to the graph and not retained anywhere, in order to fire the ended event at
the appropriate time? That's the only solution I can think of, and it seems
like that has a downside in that it makes it trivial to create an
accidental memory leak where a GCable object is mysteriously not getting
GC'd despite not being retained by user code.


On Wed, Sep 4, 2013 at 4:52 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Sep 5, 2013 at 11:45 AM, Raymond Toy <rtoy@google.com> wrote:
>
>> On Wed, Sep 4, 2013 at 3:03 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> On Thu, Sep 5, 2013 at 9:44 AM, Chris Wilson <cwilso@google.com> wrote:
>>>
>>>> Say you have a source node and set up an event handler for onended.
>>>>  Does the event handler fire if the buffer is not actually connected to
>>>> anything?
>>>>
>>> If the source is never connected to anything and it is GCed, onended
>>>> should not be called, right?
>>>>
>>>
>>> Whether ended is fired must definitely not depend on when GC happens. GC
>>> timing causing observable behavior changes is anathema.
>>>
>>> The answer to your first question is less clear. The question itself is
>>> also ambiguous: do you mean "not directly connected to an output" or "not
>>> indirectly connected to a DestinationNode or MediaStreamAudioSourceNode"?
>>> You'd also have to resolve *when* exactly the graph
>>>
>>
>> I was asking Chris this question.  I was thinking the node was not
>> directly or indirectly connected to the destination node.
>>
>>
>>>  connectivity check is performed. In any case, the simplest API is to
>>> fire the event no matter what, and that's what Gecko does.
>>>
>>
>> So basically, as long as you call start(...), the event is fired when it
>> is ends, no matter if the node is completely disconnected from destination
>> or not.
>>
>
> Yes. I don't see any good reason to adopt a more complex behavior.
>
> Rob
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
> waanndt  wyeonut  thoo mken.o w  *
> *
>
Received on Thursday, 5 September 2013 05:17:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC