Going back to the aim of my original email, I am starting to think that we should be cautious about any asynchronous transitions from immutability/liveness to mutability, even if accompanied by an event dispatch. Just as an explicit start() call forces a transition to a live state, some other imperative action (like forced node disconnection) by application code should be required to force a transition back to a non-live, mutable state. Otherwise the door is left open to borderline will/won't work behavior by apps that ignore the event in question.
The disconnect() action is a bit more troubling than start() perhaps. Is there the possibility for disconnect() to take some small amount of time to take effect in the audio thread, during which races wrt audio rendering are possible? Start() doesn't have that problem, the cases are not quite symmetrical.
But perhaps disconnect() on a live node already has some implicit nondeterminism. Which for some will raise the question: why is that degree of nondeterminism not considered a "race"?
. . . . . ...Joe
Joe Berkovitz
President
Noteflight, LLC
www.noteflight.com
"Your music, everywhere."
On Jul 31, 2013, at 11:44 PM, "Robert O'Callahan" <robert@ocallahan.org> wrote:
> On Thu, Aug 1, 2013 at 3:39 PM, Srikumar Karaikudi Subramanian <srikumarks@gmail.com> wrote:
>>> Good point. Liveness shouldn't depend on GC. We'd better say that only explicit disconnect() calls make the node non-live.
>>
>>
>> .. but won't that mean AudioBuffers associated with ConvolverNodes that are in "fire and forget" signal paths will be immutable forever?
>
> With Jer's proposal, yes. But I don't think there's a way around that --- nor do I think it's a serious problem.
>
> 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