>Finally using the terminal pkill instead of signal.kill() would be nice,
> as it could send SIGSTOP to all child processes.
I think that the best solution would be exploiting control groups, as
Markus suggested. They can automatically account for all child
processes and you can limit CPU consumption without completely
stopping the application.
As far as i know systemd can run from a user (see option --user in
systemd man page). Probably you can run Slack with systemd-run and
then adjust control group properties on focus/unfocus.
On 7/17/16, Sebastian Fischmeister <sfisc...@uwaterloo.ca> wrote:
> The example from Aleksey works pretty well. For example, Slack for Linux
> is just a resource hog as it constantly polls whether new messages have
> arrived. Since it's a crappy implementation, the Linux scheduler cannot
> do anything about it. But that little extension can do wonders!
>
> However, I agree, it will not work in all circumstances, and it won't
> work on memory bloat.
>
> Finally using the terminal pkill instead of signal.kill() would be nice,
> as it could send SIGSTOP to all child processes.
>
> Sebastian
>
> Markus Gutschke <mar...@gutschke.com> writes:
>
>> I am sure this has all sorts of unintended consequences.
>>
>> For instance, when you suspend an X application, it can't redraw the
>> screen. But there are definitely events that cause redraws without giving
>> focus to the application.
>>
>> Also, often it isn't the top-level process that is chewing up the CPU,
>> but
>> instead one of the child processes. You'd have to walk the entire process
>> hierarchy. And that can go wrong, if processes end up getting orphaned.
>> You'd ideally use control groups to do this correctly, but I suspect
>> systemd would get into the way.
>>
>> Maybe, instead of stopping, you could just re-nice the application. That
>> would be less invasive.
>>
>> Realistically though, Linux is already pretty damn good about
>> prioritizing
>> applications. So, I suspect you won't see as much of a benefit as what
>> you
>> are hoping for.
>>
>>
>> Markus
>>
>> On Sun, Jul 17, 2016 at 1:01 PM, lexa fedotov <l...@cfotr.com> wrote:
>>
>>> Hi Sebastian,
>>>
>>> I can propose a way to automatically suspend/unsuspend application
>>> when it loses/regains its focus.
>>>
>>> Please take a look at this snippet.
>>>
>>> local signal = require("posix.signal")
>>> ....
>>> awful.rules.rules = {
>>> { rule = { class = "Firefox" },
>>> callback = function(c)
>>> c:connect_signal("unfocus", function () signal.kill(c.pid,
>>> signal.SIGSTOP); end);
>>> c:connect_signal("focus", function () signal.kill(c.pid,
>>> signal.SIGCONT); end);
>>> end}
>>> }
>>>
>>> I'm not sure that automatic process suspension will play nicely with
>>> all applications, but you could try and see for yourself.
>>>
>>> On 7/17/16, Sebastian Fischmeister <sfisc...@uwaterloo.ca> wrote:
>>> > Hi,
>>> >
>>> > There are a lot of apps who consume cpu time in the background while
>>> > I'm
>>> > not using them. Does anyone know a good way to incorporate automatic
>>> > process suspension upon unfocus to awesome?
>>> >
>>> > For example, I have gmail open in a dedicated browser (e.g., I only
>>> > use
>>> > firefox for this). When I unfocus firefox, awesome should send SIGSTOP
>>> > to the firefox process. When I focus on firefox again, awesome should
>>> > send a SIGCONT.
>>> >
>>> > Candidates for this behaviour includes browsers in general, but also
>>> > virtualbox, and even some messenger apps (I get the notification on my
>>> > cell phone anyways).
>>> >
>>> > Any ideas?
>>> >
>>> > Sebastian
>>> >
>>> > --
>>> > To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
>>> >
>>>
>>>
>>> --
>>> Kind Regards,
>>> Aleksey
>>>
>>> --
>>> To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
>>>
>
--
Kind Regards,
Aleksei
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
