[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Killing backticks when bouncing screen.
From: |
Malte Skoruppa |
Subject: |
Re: Killing backticks when bouncing screen. |
Date: |
Thu, 22 Jan 2009 16:04:20 +0100 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080923) |
Hi Chris,
Sorry if my original post was unclear.
Some data obviously needs to be updated frequently to be useful.
My intention was to avoid the overhead of having three or four scripts
take off every second or so.
[..]
For CPU & network activity where a one-second refresh interval makes
better sense, I decided that starting a process for each and every
update was totally wasteful.
Well, the way I see this, there are 2 possibilities:
1) either you have your script loop infinitely (sleeping 1 second or so
after each iteration), while using backtick with lifespan and
autorefresh set to 0, and what screen then supposedly does is loop
infinitely as well, looking if there's a new output from your script
frequently
2) or you have a script that does not loop at all, and just executes the
code once, and have backtick start it every second or so, like I
suggested; in this scenario there's just one loop being executed, from
screen
You are saying that you prefer possibility 1) as you want to "avoid the
overhead of having three or four scripts take off every second". But
this would really only make sense for a script that looked like this:
# do some expensive pre-computing stuff
while true {
# do something cheap
sleep 1
}
...because then, you would avoid to run the expensive pre-computing
stuff over and over again.
But I don't think yours looks like this, or does it? The way I
understand you, you have a big outer loop around your script, so whether
screen loops every second and executes the script again and again, or
whether you do the loop in the script yourself, actually makes little
difference, as in the end, it's the same code that's being executed
again and again, at the same interval.
Plus, how complex can these scripts be? I mean, monitoring CPU or
network activity is just reading some stuff from /proc and reformatting
it somehow and output it, possibly also using some intermediate program
like sensors, but anyhow, this can't be that expensive, can it?
It's not that I'm absolutely trying to convince you to use backtick in
this way... do as you like... I guess I'm just trying to say that
starting a few simple scripts every second probably produces much less
overhead than you might think :-)
Of course, you can also have these kind of "daemons" that continuously
output monitoring information, in the background.
As I was testing the layout of my hardstatus line the other day, I
eventually noticed--thanks to my monitoring, and the laptop's fan
kicking in :-) .. that I was using dollops of ram & cpu cycles .. well,
it turned out some 20-30 instances of my scripts and the related sleep
subprocesses were still running in the background.
Shouldn't this be enough evidence that solution 2) is actually the more
expensive one, in the long run?
So you would have to kill the scripts somehow when you terminate
screen... I guess this could be pretty tricky, maybe someone else here
has an idea how to achieve this easily. But even if you get it to work
like that, I wouldn't feel this is a neat solution... well, to each his
own ;-)
Just my 2 cents...
Cheers,
Malte
Re: Killing backticks when bouncing screen., Trent W. Buck, 2009/01/23
Re: Killing backticks when bouncing screen., Gerhard Siegesmund, 2009/01/23