Forums Bug Reports while loop freezes command prompt

ok so if I make a batch file

save as d:\ip.bat
if i type in mirc:
//run d:\ip $chr(124) clip
then ip.bat instantly pops up and copies to the clipboard then closes almost instantly.
but when i want to output to @win
so i use the code:

It works exactly as expected except there is a very long pause (about 15 secs) while the cmd window is open as if the while loop is freezing it
It is my understanding that while loops shouldn't freeze outside programs althow i could be wrong.....

There are so many things wrong with that code, it's really quite amazing it works at all!

Lets ignore the fact that I have no idea what this 'clip' command actually is, and just 'assume' it's some magic program that takes STDOUT from a command-line application and inserts it into the clipboard..

You're doing a hard-loop checking the content of a variable of which doesn't exist, which basically sucks *ALL* CPU cycles away from everything else. So whilst looping hard, you may get lucky and have the 'odd' cycle of which the previous 'run' can actually do something in. Yay.

You'd be better off breaking the alias int two parts, one to do the ipconfig call, the other, after a /timer, reads from the clipboard. You could even make it a self-calling timer so it could wait longer if necessary.

Yes you're right the clip command copies the output of any command-line application to the clipboard... see http://www.ss64.com/nt/clip.html
I understand that I'm doing a hard-loop to wait for something to exist in the clipboard... and I prefer that mirc freeze until the output is caught so that was on purpose (and it would only be for a split-sec if the cmd program didn't freeze up), which is what I don't understand. Why does the command-line program (ipconfig) freeze as well from the loop?... I thought (read from other posts on these forums) that even infinite loops wouldn't affect anything outside mIRC because of cpu time pieces or something (I know nothing about how it works just from what I read from replies to multi-threading feature suggestion posts)


Besides the hard-loop (1 thing) what else is wrong? (What are these so many things?)

and I know how to get around the problem... No Work-Arounds Needed Thx.

Just trying to condense.
Question:
Answer:
The cmd freezes (i.e. replies that slow) AS mirc freezes in the infinite loop (i.e. eating all that cpu - thats not a bug)

you are wrong about an infinite loop in mIRC not affecting other programs. CPU cycles are devided by demand, and if mIRC demands them all (due to the infinite loop) it will get nearly all of it which causes your whole system to freeze. this includes your command line which will then take much much longer to process then normal so the while loop goes on even longer.

use the /sleep script which is on this forum somewhere or use any other method to counter this problem. infinite loops are never a good solution really :-P

When any program (not just mirc) does something that consumes as much CPU as possible, other programs do work, but they do so more slowly, assuming that all these programs have the same process priority (usually 'Normal'). If you lower mirc's priority below 'Normal', other programs will be much more responsive. The opposite would happen if you raised mirc's priority and then ran the loop; other programs would become very sluggish (almost unusable). You can find lots of info on process priorities, scheduling etc on the net, the bottom line is that what is happening with your script is normal.

As others have pointed out why, here is a way to get the same result.


BTW: there isn't a need to clear the clipboard before piping the output to clip.exe

It prints the current contents of the clipboard to @ipconfig ?

Yes, after first running cmd.exe /c ipconfig|clip it then puts the result in @ipconfig

I copied your alias and pasted it into the script editor, then I ran your alias and the current contents of the clipboard (your alias) was printed to @ipconfig.

Do you have clip.exe in %systemroot%\system32?

Edit: Or elsewhere in the 'path' envar for that matter.

There's no clip.exe anywhere on my system. (XP Pro SP2)

Well there is why it won't work for you. The OP does have clip.exe.

Well that makes sense

Okay, if anyone is interested, I (sort of) made an /exec alias with the use of deegee's code. (Permission was asked beforehand.)

Code: Here.
Img: Here.



*edit*

Could be buggy, though?

Ok thanx for the replies I understand a little better, But...
I'm still confused about the priority part...
So if multiple programs (including mirc) are running with the "normal" priority for time slices from the cpu... I thought that the application layer was designed so that each process got it's own time slice no matter what, which prevented 1 locked-up program from freezing others... So how does mIRC bypass this and take *ALL CYCLES* from cpu?... Is it that mIRC changes priority to highest when a "hard-loop" is issued?

(btw I apologize for posting this in the bug reports now that I know this isn't a bug)

EDIT: Ok also you guys said the "hard-loop" hogs *ALL* CPU cycles but this is not the case... I can purposely start an infinite loop in mirc and run all my other programs just fine... Firefox, Photoshop, and as a matter of fact I can watch an HD Video during an infinite loop and the only thing that does freeze is the cmd prompt... why is this? (btw I'm editing this post with an infinite loop in mirc going)

EDIT2: Ok I was also able to run a CMD Prompt and use ipconfig with no sluggishness at all

same "hard-loop"

while (!%a) {
%a = $null
}

EDIT3: Sorry for all the edits, but I also wanted to state that when I use the original alias in the first post... I can have a video running in the bg... then do /ipconfig in mirc... and during that 15 sec. freeze (mirc and cmd are frozen) The video doesn't stutter 1 bit, and all my other programs work fine as well...... In case it was thought that I was doing something different.

I don't believe the problem has anything to do with scheduling (allocating time-slices to the CPU) as others have suggested. As you've mentioned, if other programs have the same priority as mIRC and are requesting CPU time then they will have more or less equal allocation as mIRC.

I think the issue in your original case is that you are constantly accessing the clipboard from mIRC while the clip.exe process is trying to write to it. The clipboard is essentially a global resource so if mIRC is accessing it clip.exe has to wait until mIRC releases it again.

Note that this is just an assumption on my part, I haven't tested to confirm this.

shyt I dunno, kinda makes sense but thought global resources were shared equally and not in order... *still confused*
maybe khaled could shed some light on the subject...

What you said does make more sense than anyone else's post
I Do think Becker, who said "hard-loops" suck *ALL* cpu cycles, Horstl, who agreed with him, Doqnach, who said I was wrong, and qwerty, who agreed with all 3.... Were all wrong, as I stated above the "hard-loops" don't freeze anything, or "make anything slower"...

I think you're right thow, just don't know how...

Thanx all, Bye.

Think about it. Have you ever tried compressing a large file in WinRAR and then tried playing a game that uses a lot of CPU resources without WinRAR put in the background? It will run too slow to do anything in it. This is because WinRAR purposely uses as much CPU as possible in order to complete more quickly.

This is true all around the board. Have you ever had a program freeze and suddenly other programs stopped working until you killed the process? Programs should all have equal access to the CPU, but that isn't really a good use of the CPU because some program don't need as much CPU and some need more.

Now, take that and add it into multiple programs trying to access the same data/file/memory location/etc. When that happens, everything trying to do so will be frozen.

In any case, avoid looping when there isn't a reason to do so. Especially a loop that has no internal way to break out of it. (Checking a variable that *may* be set at some point is not a real way to break out of a loop). Remember that loops are very fast assuming nothing major is being done in them. You may have hundreds or thousands per second. That's a complete waste of resources even if things didn't freeze on you. A timer, even one set to trigger ever 100ms or whatever, would be much better. It would save a LOT of resources.

Yes, I completely Understand as I stated many times that using the while loop is not efficient and understand how it freezes up mIRC and waste resources ect ect... But what was in question was why the cmd box freezes with the command in the first post... I now think I got it narrowed down to something to do with mirc trying to read the clipboard the same time the clip command is trying to write to it (Thanx to starbucks) so What you assumed is the same as the others at the beginning is wrong, it's a good theory but it's not what is happening... mIRC does not hog the cpu with an infinite "hard-loop" nor does it heighten it's priority in any way similar to winrar... everything still runs fine and at normal speed... (except mirc of course, and the cmd-box from 1st post)

edit:(this is just what is understood from behavior, final word would have to come from either khaled or someone with some good programming knowledge of how it all works)