If the amount of data coming in is more than we can hold in our
buffer, we resized the buffer by doubling its size. However, there
were two(!) issues here:
* If this was the first resize, the buffer size was set to 1024. This
may not be enough (i.e. there may be more than 1024 bytes to process).
* In all other cases, the buffer size was doubled. However, there is
still no guarantee the buffer is large enough.
Fix by looping until the buffer *is* large enough.
When the script module received multiple transactions in a single
batch, only the first were processed. This lead to multiple,
unprocessed transactions stacking up in the receive buffer. Every time
a new transaction was received, we popped the oldest transaction from
the buffer, but never actually getting to the last one. This is
perceived as "lag" by the user, where the bar displays outdated
information.
Closes#221
All FDs should now have the CLOEXEC flag set, and thus there’s no
longer needed to manually loop “all” possible FDs and (trying to)
close them.
Note: the alsa module (alsalib, actually) is “racy” - while booting
up, it temporarily opens the asoundrc file without CLOEXEC. If
e.g. the script module starts its script inside this window, it’ll
have a leaked FD. Not much we can do about it though :/
Closes#169
This ensures we don’t leak FDs when exec:ing e.g. on-click
handlers.
Note that the comm-pipe FD is *supposed* to stay open when we execing
the script. This is handled by the call to dup2(), which drops the
CLOEXEC flag. Since dup2() is called after the fork, the dup:ed FD is
never visible in the “parent” yambar process.
When set to a non-negative value, the script module will call the
configured script every <poll-interval> second.
In this mode, the script is expected to write one tag set and then
exit.
This is intended to simplify the implementation of scripts that would
otherwise just do a loop + sleep.
Closes#67
Assume that a closed pipe means the child died. Even if it hasn’t, we
can’t read anymore from it. We’ll end up killing it anyway before
returning from run().
* Verify int/float/bool values are that, and nothing else
* Verify tag ranges are integers
* Verify a range tag value is inside its range
* Don’t allow anything but false|true for booleans
User is expected to send ‘false’ or ‘true’. But we were parsing the
value using `strtol()`. This caused all bools to be false, since
`strtol()` would always return 0.
This module exec’s a script (or binary), specified by the ‘path’
attribute in the configuration.
It then reads tags from the script’s stdout.
The format of the output is:
tag|type|value
tag|type|value
<empty line>
I.e. the script writes N tags followed by an empty line. This
constitutes a transaction.
When a new transaction is received, its tags replaces *all* previous
tags.
