output applet hangs when commands take longer to execute than update interval

Found a solution to circumvent this problem and now my monitor script reads:

#!/bin/sh
system=`since /var/log/*.log | sed '/nothing new/ d' | sed '/message repeated/ d' | sed '/==>/ d' `
test "$system" != "" && echo $system >> /home/user/.all.log
tail -n 10 /home/user/.all.log
test $(stat -c "%s" /home/user/.all.log) -gt 1000000 && echo "Log file exceeded maximum size" > /home/user/.all.log

Anyhow, this is clearly not the desired behavior for the screenlet.

Also, the beauty of the approach is strongly limited by the unresolved question: https://answers.launchpad.net/screenlets/+question/58968

So the solution would be to not call the update routine before the previous update is finished. It's just to add one variable to check that. Anybody want to fix it?

Altering the way the output lines are selected will avoid this problem (the while loop in on_draw takes far too long - even if we delay following updates we have to wait unnecessarily long for the initial draw on big input).
I already implemented a prototype of a new line selection logic and it works well and fast in straightforward cases. But there are a few things I have to respect further (wrapping lines, reverse output) which are not working well now.

Fixed referring to the description contained in title of this bug report: long command outputs are now processed in acceptable speed.
What is not altered is the behaviour regarding commands that do not return as this will not work with the current design of the Output screenlet. It may be possible to alter the screenlet design to work asynchronously, consuming the output while the original process is still running, but this would be a great change and may be better implemented through a fork.
Additionaly fixed is the content calculation, so the problem described here https://answers.launchpad.net/screenlets/+question/58968 should be solved as well.