Infinite Loop check..

Sorry for postin it in GD..but thought it best suite here since there is no specific algorithm board..


Well how do user action programs work... For example when a key mouse button is pressed do sometin.. They work so neat.. but when i implement it in my programs (DOS :() I use a continous loop to check the mouse button every loop cycle before doin the required operation..THis seems to be so primitive and taking up resources and slows the entire program... How do languages like VB etc manages it.. (mouse actions..) do they also run an infinite loop to check the mouse status or does it make use of sometin like interrupts etc..

Vasanth

You could stick the mouse controls on a different thread (don't ask me how to do that, I haven't learned it)

Direct Input (part of DirectX) will give you the "cumulative" movement since the last time you checked it every time you check mouse movement, etc. It stores it all in a buffer until you're ready for it.

Yep, infinte loops. However, there's a catch. Traditionally, the message-handler functions (i.e. GetMessage, PeekMessage, etc.) are blocking. Hence, if there's nothing to be had, the function will wait and will not return.

I have an example of blocking a continuous loop waiting for keyboard or mouse events in a console in part 5 of my tutorial here. If you're working in real 16 bit DOS, then you'll need to find appropriate API routines.

Quote:

---

Originally posted by adrianxw
I have an example of blocking a continuous loop waiting for keyboard or mouse events in a console in part 5 of my tutorial here. If you're working in real 16 bit DOS, then you'll need to find appropriate API routines.

---

thanx that was soe help.. but how does it achieve that.. (blocking funtion).. without running the loop how does it know sometin has happened.. just a doubt to know how it works internally..

wow you have a nice site there.. hope you dont mind if i just borrow the colour scheme for my site... the colours look plesant

>>> the colours look plesant

I chose the colours because they conform to the 256 colour scheme recomendations, i.e. they should look the same on older machines that only support 256 colours, (a lot of third world people do not have access to 24bit colour systems - sad but true). To generate them use combinations of RGB() with the values:

0x00
0x33
0x66
0x99
0xcc
0xff

... I did schemas for all the colours, but only the green, yellow, cyan and grey looked any good.

Not meaning to bump, but how does a program achieve blocking status?

Quote:

---

Originally posted by golfinguy4
Yep, infinte loops. However, there's a catch. Traditionally, the message-handler functions (i.e. GetMessage, PeekMessage, etc.) are blocking. Hence, if there's nothing to be had, the function will wait and will not return.

---

PeekMessage can return when there's no messages.

golfingguy, blocking just means that the function will not return until you get an "answer" kinda like scanf()

Yeah, but how would it do this while still not consuming immense processing power? Does it put the current thread into low priority while looping?

I would suspect that the scheduler sets a flag in the OS's dispatch table to render the task as not "ready to run", and posts an interrupt handler on whatever event the task is "waiting" for. When the event interrupt occurs, the "ready to run" status is reset.

That is how it is done in VMS, and the NT core was designed by the same guy.

Can an app utilize this? Or is it an undocumented thing?

There are always ways to do things, however, the how tends to depend on the what. You can suspend your task any number of ways, there are a whole list of "waitable" OS objects you can suspend and wait for. You choose which one is relevent to your application.

Look up WaitForSingleObjectEx() at MSDN, it'll give you a start as to how to wait on some things. It is not the only way.

Quote:

---

Originally posted by vasanth
thanx that was soe help.. but how does it achieve that.. (blocking funtion).. without running the loop how does it know sometin has happened.. just a doubt to know how it works internally..

wow you have a nice site there.. hope you dont mind if i just borrow the colour scheme for my site... the colours look plesant

---

At a really low level, its like this: in some events (not sure which) there's a controller called the PIC in your computer that accepts (or denies!) requests from certain hardware to 'interrupt' - which means exactly what it sounds like, tells the CPU to interrupt the current code and jump to 'interrupt handling code' - the event handler.

When your device doesn't use interrupts, it's values are available by looking at a specific port number (well now that I think about it, that's usually the case with interrupt devices as well!) And there are usually threads (on an OS level) that check these ports for changes, and can even issue the interrupts themselves.

And now that's probably more than you'll ever want to know about how all that stuff works. (Am I good, Compuboy?)

Actually it's not that much..
And I wanted to clear one thing up: in ALL cases with an x86 system (that means Intel proc, or AMD) there's a PIC controller. When I said 'in some events' I meant that some hardware produces interrupts on events, and some don't.