On Wed, 15 Aug 2012, Dave Mielke wrote: > [quoted lines by Nicolas Pitre on 2012/08/15 at 17:29 -0400] > > >This issue can be mitigated greatly by making the eSpeak driver speech > >processing call into a thread of its own. Attached is a patch to make > >the eSpeak driver threaded. > > I rather suspect that a more general solution would be better than dealing > with > each driver on an individual basis.
Possibly. As a first step, I'd still recommend applying this patch in the mean time. This solves a long standing usability issue for me (the symptoms were reported by someone else here already). > >Is this enough to ensure the repeated key problem will never happen > >again? > > No, because any otehr speech driver, or even, I suppose, a slow braille > device, > could cause the same symptoms. Well, we do control the braille driver code. None of it should ever block or require significant CPU cycles. Speech drivers are somewhat different as they often rely on external libraries. And so far only eSpeak seemed to cause problem. At least that's the only one that generated issue reports. So this might make sence to move the threading support up a level, making it generic to all speech drivers. > >Maybe the Linux keyboard filter code would benefit from being > >moved into a thread of its own as well. > > Yes, I've often thought that this should be done. I just haven't done it yet. > > Are we that the point where we should just assume that Linux has Posix > threads, > even in boot environments? I kept the ability to build the eSpeak driver without thread support in my patch. I can't say if boot environments generally have pthread available. Nicolas _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://mielke.cc/mailman/listinfo/brltty
