- From: K. Gadd <kg@luminance.org>
- Date: Wed, 4 Sep 2013 22:16:41 -0700
- 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>
- Message-ID: <CAPJwq3UGOyukOyoRdwzPbJ3EbDU8mSEcMwoqe0kiFtQgjXd=7Q@mail.gmail.com>
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