On Mon, 27 Jan 2014, Dave Mielke wrote: > BRLTTY-5.0 has been released.
[...] > The most significant change in this release is that brltty is now event-based > rather than polling-based. Kudos to Dave for this achievement. This may seem trivial to the uninitiated, especially as nothing really changed on the surface when using BRLTTY. But this still means major and non-trivial changes to the way BRLTTY operates internally. As I helped Dave with some issues in the course of this development, I was able to appreciate the extent of the effort Dave has put into this. Why is this so important if nothing has changed on the surface? In short, this has to do with power management and battery life. Previously, BRLTTY would go to sleep for 40 milliseconds, then wake up to inspect the screen content and the braille display keys in case something changed, perform the necessary braille content update, and go back to sleep for another 40 milliseconds, and wake up again, etc. In programming jargon this way of doing things is called "polling". The main advantage of polling is a much simpler program since polling is very easy to implement. It is also much easier to debug as everything is performed always in the same sequence all the time. However, polling comes in the way of power management which wasn't much of an issue when BRLTTY was initially developed almost 20 years ago. Designers of today's laptops and portable devices like Android phones and tablets are doing anything they can to make batteries last longer while still making the batteries themselves as small as possible to keep the size and weight of the device down. One solution for reducing power consumption consists of simply shutting down the processor when there is nothing to do. For example, when your smart phone is done redrawing the screen with some web page content, it may well simply turn itself off to save power while still keeping the screen on. As soon as the screen is touched, a key pressed, or if a call comes in, then the processor is quickly booted up again and execution resumes where it left in order to react to the new event. Those processor shutdown and wake-up operations are good for saving power overall, but they take some time to perform, sometimes in the order of a few milliseconds. And those operations do consume some amount of extra power as well. As you might start to realize, BRLTTY's 40-millisecond polling loop is not helping power consumption at all if it forces the processor to wake-up, shutdown, wake-up, shutdown, and so only to notice that the screen content has not changed and no keys were pressed on the braille display in most cases. Not only this has the potential to increase power consumption, but the processor ends up spending a significant amount of time simply suspending and resuming itself instead of doing useful work. To mitigate this effect, power saving measures such as suspending the processor are applied only when the system has been doing absolutely nothing for a little while. But if BRLTTY is running its poll loop 25 times per second then this never makes the system appear idle enough for power saving features to kick in. So it was time for BRLTTY to adapt to the modern world and behave appropriately. Hence the new "event based" mode of operation. In short, this means that BRLTTY now tells the operating system what events it is interested in, and simply goes to sleep until one of those events is signaled. If no events are signaled, BRLTTY simply doesn't wake up at all and the processor may shut itself down for a much longer period while you are reading the braille display content. Simple, right? Actually this is not so simple. Event based programming, unlike polling based programming, must react to any event in any order at any time in any random sequence. This makes the program much more complex and prone to subtle bugs we call "races". For example a race may occur if the processing of an event requires various pieces of information and another event changed some of that information half through. A concrete example of a race that we had to identify, and then deal with, broke auto-speak and keyboard echo. When the Linux console receives a new character when you press a key on the keyboard, then the kernel performs two distinct operations. First it draws that character on the screen at the cursor location, and then it moves the cursor one position to the right. The way screen update events are signaled by the kernel, you get notified twice by the kernel in this case. When this happens on a multi-processor system, the kernel could be doing the screen update on one CPU at the same time BRLTTY is processing signaled events on another CPU. If BRLTTY sees both events together it does see a new character being typed and perform character echo normally. But if it sees the new character first and sends the speech request for that character, and then sees the cursor moving to a blank position next to that character just like when arrow keys are used and mutes the speech synthesizer in that case, the end result becomes a very random keyboard echo where some key presses are pronounced and some are not. This race existed before BRLTTY became event based of course, but the odds of BRLTTY executing its poll loop right in the middle of this screen update sequence were extremely low. Now that BRLTTY is able to react at the very moment a change occurs, the timing is much more likely to be right. And yet, this is true on some systems and not on others depending on the CPU speed and other variables which sometimes makes reproduction of this type of problem by a developer very difficult. This is not the only race or issue that needed attention of course. Many other funny behaviors which cause was subtle and unexpected appeared and were fixed. And the code had to be rearchitected to fit the event based programming model in the first place, etc. Simply to say that Dave did a great job and has put a lot of efforts in this work over several months so that BRLTTY appears to just work as before, with the indirect but still well appreciated side effect of prolonging the battery life of your laptop or portable device. I therefore wanted to give you all a sense of the significance the 5.0 release has for justifying a major version number bump, even if nothing revolutionary over the previous release is presented to the casual user. So thank you Dave for your dedication to this project. This is highly appreciated. 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
