DoEvents equiv?

[Mark Hammond]

Carlos Ribeiro wrote:

> Since Win31, and specially since Windows 95, we have seen the preemptive 
> part of Windows growing bigger. Now the OS does have something closer to 
> a scheduler. Each process has it's own message queue, and Windows does 
> some work to keep everything running without any process starving. If a 
> single process stops checking the message queue, the process is dead 
> though. When it happens you need to Ctrl-Alt-Del|Finalize to kill the 
> process.


Correct.  But this has _nothing_ to do with the scheduler.  It does not 
matter if the offending app is using zero CPU, or is blocked in a system 
call that yields to other processes.

> Now what's the problem here? *In my experience*, PythonWin is 
> particularly irresponsive sometimes. 


It is, primarily when executing long running scripts.  You are correct 
that this is a flaw in Pythonwin, and indeed why apps like Komodo run 
their Python programs out of process.


>> I disagree.  If you are writing a GUI app, you should design an 
>> architecture so that the GUI does not block for long periods of time.


> AFAIK, the problem is that my script is using all CPU time available. I 


Nope.  It is because Pythonwin is not processing it's event loop.

> think that the problem can't be easily solved inside PythonWin (I may be 
> wrong). What is the solution? I was thinking of using explicit 
> yield()-like calls to keep everything running fine, even in the middle 
> of a CPU intensive process. I've checked the Windows SDK reference for 
> some help. It seems that what I'm looking for is the Sleep() call:
> 
> Sleep


Nope.  Sleep just yields the processor.  It has no effect on the 
underlying problem - that Pythonwin is not processing messages.

> Where do I need to call it? 


Whereever you want your program to do nothing for a period of time.  It 
will have NO affect on the underlying problem.


> I hope I have made myself clear on the intentions side. 


You have.

> There must be 
> other ways of making PythonWin more responsive changing only its 
> internals, and leaving Python untouched. 


Unless the app does lots of "print" statements, there is not much we can do.

>> What happens if during your PumpMessages() call, the user actually 
>> selects a different menu item, and recursively starts an operation?
> 
> As I said, I'm not writing GUI apps. My problem is trying to stop some 
> simple (but long running) scripts form inside PythonWin.


OK - in this case it is _me_ writing the GUI app in question.  So what 
do _I_ do in that situation.


>>> Also, note that this call is not available under Linux, so you have 
>>> to take this in account also (test the os, load pythoncom only on 
>>> Win32...).


That won't be a problem - pythoncom only runs on Win32 anyway :)

> This problem does not apply to Linux; 


I think you will find it does.  If an app running on Linux uses an event 
queue, the same problem will exist.

Mark.