Using core.callLater / wx.CallLater / wx.CallAfter

[seanbudd]

@davidacm posted

Due to a conversation on #13550
Where it's suggested that wx.CallLater is not safe and opted to use a less accurate method, my doubt about the use of wx.CallLater resurfaced.
I know many of us developers have used this feature, but it's commented that there are risks in using it.
I'm asking here again, so that the more experienced ones could comment on what are the disadvantages of using wx.CallLater (or core.callLater), since sometimes a simple python timer is not feasible.

[seanbudd]

At the root of the problem, performing tasks after a delay is not something that should be handled by our GUI library.

Some issues that arise from this:

• Using wx.CallLater/wx.CallAfter always runs the task on the GUI thread.
  • If the GUI thread is slow, blocked or unresponsive, the tasks will not run as expected. A somewhat related issue: Modal dialog blocks core if CallAfter fires within wx.Yield (e.g. waiting for caret movement) #6800
  • It would be safer and generally better to have a separate thread for queuing timed tasks.
• There's a history of buggy behaviour with the underlying architecture of wx.CallAfter (google results). While most (all?) of these have been solved, this flags the issue of relying on a GUI library to perform delayed tasks.

This list is not comprehensive, just highlighting the major surface level issues.