[comp.windows.ms] Yield?

parker@grapevine.uucp (Parker Waechter) (01/06/89)

how does one use the Yield call?

I have a function which basicly does a big for loop on every WM_PAINT
and I would like it not to hog the cpu the whole time.  I tried inserting
the "Yield" inside the loop, but other aplications still seem frozen.

any hints?
				Parker
-------------------------
Oh yeah....these are my questions/opinions/requests...not anyone elses.

bturner@hpcvlx.HP.COM (Bill Turner) (01/10/89)

> how does one use the Yield call?

One doesn't.  If your application has windows, then Yield is a no-op.

If you want to yield control, you must empty the message queue.  That
means either calling GetMessage to empty the queue (and block till a
message arrives), or using PeekMessage.  Thus, you can do something
like:

    while (more processing required) {
	do processing;

	while (PeekMessage(&msg, hWnd, 0, 0, TRUE)) {
	    TranslateMessage(&msg);
	    DispatchMessage(&msg);
	}
    }

You do *NOT* want to throw away the messages comming in during this
loop, so you have to be careful of reentrancy problems.  As far as I know,
this is the only way to yield during message processing.

--Bill Turner

dick@venera.isi.edu (Richard Gillmann) (01/11/89)

In article <33575@grapevine.uucp> parker@grapevine.uucp (Parker Waechter) writes:
>I have a function which basicly does a big for loop on every WM_PAINT
>and I would like it not to hog the cpu the whole time.

There's no simple way to do it.  You can use PeekMessage to process
the queued messages, but I've never found a way which is totally
transparent -- handling accelerator keys is a puzzler.

One alternative is to break your painting into a number of smaller tasks
and do them in response to WM_TIMER messages, with the timer set up by
WM_PAINT.  In this way, other messages can be processed between the
timer messages.

bturner@hpcvlx.HP.COM (Bill Turner) (01/12/89)

> One alternative is to break your painting into a number of smaller tasks
> and do them in response to WM_TIMER messages, with the timer set up by
> WM_PAINT.  In this way, other messages can be processed between the
> timer messages.

The only problem with this is that your application will still control the
CPU, starving all other tasks.  Task switching isn't done unless the 
messgae queue is empty.

Let's hear it for a non-preemptive multitasking system!  :-)

--Bill Turner

dick@venera.isi.edu (Richard Gillmann) (01/13/89)

In article <106580014@hpcvlx.HP.COM> bturner@hpcvlx.HP.COM (Bill Turner) writes:
>> One alternative is to break your painting into a number of smaller tasks
>> and do them in response to WM_TIMER messages, with the timer set up by
>> WM_PAINT.  In this way, other messages can be processed between the
>> timer messages.
>
>The only problem with this is that your application will still control the
>CPU, starving all other tasks.  Task switching isn't done unless the 
>messgae queue is empty.

Not true!  The WM_TIMER method does work.  I have used it for several
programs.  Other tasks are not starved, because the queue is empty between
timer messages.  Of course, you must set the timer interval to a sufficiently
large value, so that there are periods between timer messages when the queue
is empty.

But I do agree that a real pre-emptive multitasking system is much nicer.
All this falls out automatically in PM.

bturner@hpcvlx.HP.COM (Bill Turner) (01/14/89)

>>The only problem with this is that your application will still control the
>>CPU, starving all other tasks.  Task switching isn't done unless the 
>>messgae queue is empty.
>
>Not true!  The WM_TIMER method does work.  I have used it for several
>programs.  Other tasks are not starved, because the queue is empty between
>timer messages.

You're right; I was thinking of the other technique that was proposed,
doing a chunk of processing and sending yourself a message to continue.  Sorry.

--Bill Turner