Re: Killing backticks when bouncing screen.

[Adrian Rollett]

Hi Malte,

just going to chip in with my own 2 cents - your points are all valid, 
except for one point. Screen is actually not too good with running 
constantly refreshing backticks in my experience. It will block while 
firing up the processes, rendering it unusable for a couple seconds 
every n seconds, where n is how often you have it set to refresh. 
Obviously, I considered this less than optimal behavior, and moved to 
placing the loop in the script. I don't know if this behavior is due to 
a lack of threading, or what. 

To the OP: I would simply modify your scripts to check if there is 
another copy of themselves running when started up, and kill it if so...

cheers,

Adrian
________________________________________________________
Adrian Rollett                          | Systems Manager
address@hidden          | [Central Web address@hidden



On Thu, 22 Jan 2009 09:04:20 -0600, Malte Skoruppa wrote:
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> screen-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/screen-users