The module has a poll timeout because it needs to periodically check if
it is shutting down. Otherwise, it would be stuck polling and the bar
couldn't shut down until the script produces a new line.
However, this causes the bar to wake up intermittently (currently
~40/s) due to the 25ms timeout.
Bumping this to 250ms still gives us timely shut downs and caps the
number of wake ups to 4/s.
This is only a stop-gap solution, ideally the script runner is
integrated into the main event loop and uses its polling handles which
don't have to wake up to check for a shutdown.
Ref #1778
Ref #2337
If a script module is waiting on a non-tailed script to finish, polybar
cannot shut down until the script has terminted.
To remedy this, we use the same polling loop as for tailed scripts which
checks if it needs to terminate after every iteration.
Fixes#1978
* Move tail and non-tail handler to method
Defining them in the constructor is ugly.
* script: Iterate over defined actions instead of fixed list
* Separate running logic and lock m_output
* Include POLYBAR_FLAGS in linker flags
* Stop using m_prev in script_runner
* Join module threads in stop function
Joining in the destructor may lead to UB because the subclass is already
deconstructed but the threads may still require it to be around (e.g.
for calling any functions on the instance)
* Cleanup script module
* Update changelog
* Remove AfterReturn class
* Remove m_stopping from script module
* Fix polybar not reading the entire line from child process.
For every `readline` call we created a new fd_streambuf. This means once
`readline` returns, the streambuf is destructed and and pending data in
its temporary buffer discarded and we never actually read it.
* Remove unused includes
