Author: Vincent Diepeveen
Date: 07:36:09 12/05/00
Go up one level in this thread
On December 05, 2000 at 10:15:31, Robert Hyatt wrote: >On December 05, 2000 at 09:58:39, Vincent Diepeveen wrote: >>Windows is a very sequential system with regard to graphics. >>If some key is hit or a mouse clicks whatever and it goes >>to LRESULT CALLBACK WndProc() or a similar LRESULT CALLBACK >>function then all other threads from the winmain process >>get blocked. Note that this is logical also if you look at it afterwards >>as windows by doing that prevents that you get parallel problems. >> >>Suppose your timer and wndproc do things at the same time! All windows >>applications might start to crash! >One obvious solution, if this problem _really_ exists (and I am not sure >because of the other parallel windows programs) is to have one process for >the GUI, one for the engine, then the engine can thread with no issues. This is exactly what i do. winmain starts a enginecommunication thread, then the engine gets started as a seperated process. If i am multiprocessing then the engine starts more proceses of its own. So just for the engine i have at least 2 processes (GUI, engine) and another extra GUI thread. Now the first problem of this blocking is if you want to close the engine. I discovered the fact that it blocks all threads again when i did next: after user selected 'quit' then in the wndproc somewhere in a subroutine of it i did something like: volatile enginestopped=0; PostMessage(enginethread,STOP_ENGINE); while(!enginestopped); To my horror the STOP_ENGINE message never arrived at the enginethread. Took me 1 week to realize that it wasn't a bug somewhere but that it was the wonderful 'garantuee' from Microsoft that prevents parallel problems. Welcome to windows!
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.