You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's common practice in Swift to use GCD with a serial queue to replace the @synchronized primitive. Thus, if this is being used from within that code, it won't be on the Main Thread. NSTimer/Timer usage here expects there to be a RunLoop present on the current thread, but that's only generally true of the Main Thread (unless you added one yourself). The current unmodified behaviour when used on a non-Main Thread will be to silently not issue your callback after the delay.
Thus I'd recommend changing this slightly to ensure that if (and only if) not on the Main Thread, the Timer.schedule... call is issued inside a dispatched call with DispatchQueue.main.async {} .
Let me know if you'd support a fork/MR with that, I have one I'm currently using that works for me in this use case.
The text was updated successfully, but these errors were encountered:
On Wed, Dec 20, 2017 at 7:34 AM, Scott Corscadden ***@***.***> wrote:
It's common practice in Swift to use GCD with a serial queue to replace
the @synchronized primitive. Thus, if this is being used from within that
code, it won't be on the Main Thread. NSTimer/Timer usage here expects
there to be a RunLoop present on the current thread, but that's only
generally true of the Main Thread (unless you added one yourself). The
current unmodified behaviour when used on a non-Main Thread will be to
silently not issue your callback after the delay.
Thus I'd recommend changing this slightly to ensure that if (and only if)
not on the Main Thread, the Timer.schedule... call is issued inside a
dispatched call with DispatchQueue.main.async {} .
Let me know if you'd support a fork/MR with that, I have one I'm currently
using that works for me in this use case.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADVkhgjOc3kY7keupLJNrpGgni2wbMtgks5tCSjogaJpZM4RIj0l>
.
It's common practice in Swift to use GCD with a serial queue to replace the
@synchronized
primitive. Thus, if this is being used from within that code, it won't be on the Main Thread.NSTimer/Timer
usage here expects there to be a RunLoop present on the current thread, but that's only generally true of the Main Thread (unless you added one yourself). The current unmodified behaviour when used on a non-Main Thread will be to silently not issue your callback after the delay.Thus I'd recommend changing this slightly to ensure that if (and only if) not on the Main Thread, the
Timer.schedule...
call is issued inside a dispatched call withDispatchQueue.main.async {}
.Let me know if you'd support a fork/MR with that, I have one I'm currently using that works for me in this use case.
The text was updated successfully, but these errors were encountered: