NSTimer stoppt nicht nach [timer invalidate]

  • Nein, der retainCount-Test ist kein Beweis, aber ein ganz gutes Indiz.

    Apples Doku ist sprachlich an der Stelle -scheduledTimerWith... nicht hundertprozentig wasserdicht, aber an der Stelle -addTimer: (NSRunLoop) steht:

    - (void)addTimer: (NSTimer *)aTimer forMode: (NSString *)mode

    Parameters
    aTimer
    The timer to register with the receiver.
    [...]
    The receiver retains aTimer.


    Das ist doch recht eindeutig, oder?

    Wir sind uns ja alle darüber einig, dass es sauberer ist, seine Timer selbst zu retainen. Ursprünglich wollte ich mit der Bemerkung darauf hinweisen, dass der Absturz auch eine andere Ursache haben kann.
    Multigrad - 360°-Produktfotografie für den Mac

  • Ein ähnliches Verhalten hatte ich auch schon einmal.
    Den Timer hatte ich auch ordentlich retained, trotzdem gings bei invalidate ab und zu ins Nirvana.
    Nachdem ich vor dem inclidate ein isValid abgefragt habe ist der Crash nie wieder aufgetreten. Der Timer war auch nie invalid.
    War unter 10.4 soweit ich mich erinnere.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.

  • @Chris
    Ja, so ähnlich war das bei mir. Ist aber schon lange her, weshalb .4 (möglicherweise sogar .3) sehr gut sein kann.

    @mattik
    Lies mal, was ich macmoonshine geantwortet habe. Ich finde es eben nicht zwingend, dass die Doku wirklich die Instanz von NSTimer meint. Das ist ja ein Wrapper, existiert also "doppelt".

    @macmoonshine
    Ich kann dir nicht folgen. Kannst du mir noch einmal heraussuchen, mit welchem Text du welche Behauptung begründet hast?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    @macmoonshine
    Ich kann dir nicht folgen. Kannst du mir noch einmal heraussuchen, mit welchem Text du welche Behauptung begründet hast?


    Mit Begründung der These, dass der NSTimer retained wird, habe ich mich hierauf bezogen:

    macmoonshine schrieb:

    So jetzt kommt der ernste Teil dieses Beitrags: Ich habe bei meinem Versuch eine Retained-Property auf Assign umgestellt und es gibt keinen Ärger, wenn der Timer abgeschossen wird. Und das funktionierte sogar wiederholt. Reicht das als Begründung?

    Gestern beim Heimradeln habe ich mir überlegt, dass der Begriff Begründung vielleicht nicht so glücklich gewählt ist. Wahrscheinlich ist experimentelle Untermauerung besser. ;)

    Als Begründung würde ich jetzt eher diese Aussage sehen:

    macmoonshine schrieb:

    Apple schreibt die Doku aber sicherlich für alle Entwickler. Also insbesondere auch für die, die sich nicht so tief in den Cocoa- und Foundation-Eingeweiden auskennen wie Du. Somit verstehe ich das Wort Timer als Objekt vom Typ NSTimer. Von einem internen Timer zu reden, auf den der Nutzer sowieso keinen Zugriff hat, macht meiner Meinung nach hier auch keinen Sinn.
    „Meine Komplikation hatte eine Komplikation.“

  • Amin Negm-Awad schrieb:

    Du meinst sicherlich den Text in Beitrag davor. Lies noch einmal nach, was ich dazu geschrieben hatte …

    Warum sollte Apple in der Doku

    Apple Doku zu NSTimer schrieb:

    Note in particular that run loops retain their timers, so you can release a timer after you have added it to a run loop.
    ein nach Deiner Interpretation vollkommen uninteressantes Implementationsdetail dokumentieren?
    „Meine Komplikation hatte eine Komplikation.“

  • Ich habe das aber immer so verstanden, dass sie ihren internen Timer ein retain schickt, nicht der Instanz von NSTimer. Deshalb hatte ich das ja unterschieden. Das hat Auswirkungen für einen One-Shot-Timer, den ich deshalb immer gleich wegwerfe (ARP).


    Ob der (interne) Timer bestehen bleibt, hat Auswirkungen, unabhängig, ob ich die Instanz von NSTimer wegwerfe, nämlich dann, wenn ich lediglich einmal feuern möchte. Was Auswirkungen nach außen zeigt, ist kein Implementationsdetail mehr.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Ich habe das aber immer so verstanden, dass sie ihren internen Timer ein retain schickt, nicht der Instanz von NSTimer. Deshalb hatte ich das ja unterschieden. Das hat Auswirkungen für einen One-Shot-Timer, den ich deshalb immer gleich wegwerfe (ARP).

    Ob der (interne) Timer bestehen bleibt, hat Auswirkungen, unabhängig, ob ich die Instanz von NSTimer wegwerfe, nämlich dann, wenn ich lediglich einmal feuern möchte. Was Auswirkungen nach außen zeigt, ist kein Implementationsdetail mehr.

    Wie macht sich das bemerkbar?
    „Meine Komplikation hatte eine Komplikation.“

  • Amin Negm-Awad schrieb:

    Die gewünschte Methode wird aufgerufen, obwohl ich die Instanz von NSTimer bereits weggeworfen habe.
    Dieses Problem tritt aber doch sowohl bei One-Shot- als auch wiederholten Timern auf, oder?

    Amin Negm-Awad schrieb:

    Ich finde die Ausführung von Methoden bemerkenswert.Du nicht?

    self.levelOfIrony = NSIronyLevelNone;
    In der Tat, ein schöne Eigenschaft der OO, die meines Erachtens viel zu wenig gewürdigt wird.
    self.levelOfIrony = NSIronyLevelNormal;
    „Meine Komplikation hatte eine Komplikation.“

  • Es ist bereits kein Implementationsdetail mehr, wenn es in einem Falle eine Rolle spielt. Den Fall habe ich dir bereits mehrfach genannt. Ob es daneben noch weitere Fälle gibt, in denen es keine Rolle spielt, ist offenkundig irrelevant.

    Wir könnten die Diskussion vielleicht fortführen, wenn du Fahrrad gefahren bist.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Es ist bereits kein Implementationsdetail mehr, wenn es in einem Falle eine Rolle spielt. Den Fall habe ich dir bereits mehrfach genannt. Ob es daneben noch weitere Fälle gibt, in denen es keine Rolle spielt, ist offenkundig irrelevant.
    Ich frage deswegen nach, weil Du diesen Unterschied herausgestrichen hast und ich Deine Unterscheidung zwischen One- und Many-Shot-Timern noch nicht verstanden habe.

    Amin Negm-Awad schrieb:

    Wir könnten die Diskussion vielleicht fortführen, wenn du Fahrrad gefahren bist.
    Wenn Du keine Zeit mehr hast, gerne. BTW. Stimmt es eigentlich, dass Du keinen Führerschein hast?
    „Meine Komplikation hatte eine Komplikation.“

  • Amin Negm-Awad schrieb:


    @mattik
    Lies mal, was ich macmoonshine geantwortet habe. Ich finde es eben nicht zwingend, dass die Doku wirklich die Instanz von NSTimer meint. Das ist ja ein Wrapper, existiert also "doppelt".

    Hab' ich gelesen (ich lese natürlich alles, was Du schreibst...). Genau deshalb habe ich ja die Stelle von addTimer: herausgezogen. Da steht eben nicht "retains the timer" oder sonstwas schwammiges, sondern "retains aTimer" (mit der Auszeichnung), wobei aTimer eindeutig die Instanz vom Typ NSTimer bezeichnet, die Du als Parameter übergibst. Schau' Dir die Stelle in der Doku nochmal an, das ist wirklich eindeutig.
    Multigrad - 360°-Produktfotografie für den Mac