[BRLTTY] New release coming soon.

[Jason White]

Dave Mielke <dave at mielke.cc> wrote:
 
> Things used to be synchronous. The code would scan forward to find a non-blank 
> window, hit the end of the screen, play the alert tune for that, go back to 
> where it was, and then update the display.
> 
> oiw things happen asynchronously. Waiting for each note of the alert tune to 
> complete opens up an opportunity for other events to run. What's happening is 
> that a screen update is running in the middle of the alert tune, before the 
> braille window coordinates have been restored to their original position.
> 
> i'm wondering if it's worth suspending the screen update thread during an alert 
> tune.

My main concern here is the additional and unnecessary write to the display,
which it would be preferable to avoid. I haven't looked at how tasks are
distributed among threads or what synchronization issues are in play, so I'll
leave it to your judgment whether there's a safe and effective solution that
wouldn't introduce further bugs. I suppose the other possibility would be to
defer the alert tones until the coordinates have been restored, bug again, I
haven't looked at it and I'd probably need to read a book on threaded
programming first.