[BRLTTY] threaded eSpeak driver

[Nicolas Pitre]

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