The application was doing a lot of work in a signal-handler. This was
not re-entrant and could interact badly with X. Since the DA event-loop
supports a timer call-back use that instead.
The last release of wmbiff included a patch by Nye Liu from Debian
bug #917467 [1]. However, the second part of that patch is not necessary.
From Andreas Metzler's comment
I am not sure about the second part of the patch. I understand wmbiff
breaking on GNUTLS_E_AGAIN from gnutls_read, because this only started
to happen recently (with TLS1.3) on blocking sockets.
What I do not get from my rudimentary understanding C programmimg is the
second part, this is in the else of "if (scs->tls_state)", so, afaiui for
non-encrypted connections. Is the change necessary there at all, is it
the right thing to retry read on EAGAIN then?
We revert the second part of the patch.
[1] https://bugs.debian.org/917467
After the introduction of MemAvailable in the kernel v3.14 one can
estimate how much RAM memory is being "used" by how much it is left
before the system starts swapping.
That is the reason why I want to monitor memory usage, to know
how close the system is to swapping. Therefore I propose to
use MemAvailable to compute the percentage of "used" memory.
Theoretically, after this patch a 100% memory usage is a more
accurate description of "yeah, we need to swap from now on".
See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773
The reason is the same as in the analogous patch for wmwifi
in commit 1e34ea7f980; it improves considerably the efficiency.
Keeping the 'interval' unchanged (set to 1 sec), with this change
the number of wakeups as measured by powertop goes from around 14 wakeups/sec
to around 2 wakeup/sec.
Base the decision to display either the interface name or essid
on a time interval rather than how many times the update() function
is called. The time interval is chosen to be 2 seconds.
The old logic would swap the display after update() was called
50 times. If 'interval' between updates is a sane value around 1 second,
it would take 50 seconds to swap the name on display.
I noticed using powertop that the number of wakeups per second
generated by wmwifi did not correlate well with the update interval,
where I'd expect approximately 1 wakeup if the update interval was 1 sec.
Strangely enough, calling the function
dockapp_nextevent_or_timeout(&event, update_interval * 1000)
in the main loop (note that I already replaced * 100 by * 1000 above)
with update_interval = 1 generates around 15 wakeups/sec here.
Calling usleep() in the loop instead leads to fewer wakeups, around 1/sec.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
