   A Timing Problem with Rendering Contexts
  Ok, my engine controls all window-related stuff in a seperate thread. Rendering and other stuff are done in other threads, so:Thread a) Create Window, manage messagesThread b) If Window is created, get Rendering Context (RC)Ok, so here''s my problem, Thread B is trying to get a RC too soon, before the window is actually fully drawn on screen or something, and it fails because of that.I''ve introduced a "sleep" delay, so that the window gets fully created and initialized by windows, before the other thread attempts to get an RC.Is there a way I can tell if a window is "done", so to speak, if it is fully created, so that I can signal other threads?Thanks for any tips on this....   [Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD]    [Yann  L.][Enginuity]  [Penny Arcade]  [MSDN][VS  RoadMap][Humus][BSPs][UGP][NeHe]"I say we take off and nuke the entire site from orbit. It''s the only way to be sure." 
  I was about to finish typing how you''d do this but I have to wonder why you make a window in one thread and get the rendering context to that window in another. It just seems wrong. ;  I make the window in one thread AND handle its messages, which means that the thread will be mostly blocking all the time.It isnt bad design to have this sort of work threads, if they by nature block a lot, like this one does, or a "receive" thread on a winsock... for example...Anyways, got any solutions?   [Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD]    [Yann  L.][Enginuity]  [Penny Arcade]  [MSDN][VS  RoadMap][Humus][BSPs][UGP][NeHe]"I say we take off and nuke the entire site from orbit. It''s the only way to be sure." ;  The "simple" solution would be to do something like this:Global:volitile bool ReadyToGo = false;Thread A) Do_Init_Stuff(); ReadyToGo = true;Thread B) while (!ReadyToGo) {Sleep(1); } Do_Rendering(); This is by no means the best way to do things, but it will work. The most important bit is really the ''volitile'' keyword. This prevents the while loop in Thread B from being optimized out.;  Just suspend the rendering context thread until the other one is done? I was going to say use a critical section that is created in the signalled state but if this is a one-time deal that isn't necessary.Edit: don't busy-wait on some global variable like the AP is suggesting, at least use some method of synchronization.   [edited by - antareus on February 15, 2004 12:22:05 AM];  uh?!You guys are missing the point. I need to know WHEN it is safe to get a Rendering Context, in other words, when will the window be totally initialized by windows......so that my (b) thread doesnt try to get a rendering context while windows is still seting up the rendering window...Thats the main problem. Do windows send back any sort of message indicating "im done"...?   [Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD]    [Yann  L.][Enginuity]  [Penny Arcade]  [MSDN][VS  RoadMap][Humus][BSPs][UGP][NeHe]"I say we take off and nuke the entire site from orbit. It''s the only way to be sure." ;  No, you are missing the point.quote:I need to know WHEN it is safe to get a Rendering Context, in other words, when will the window be totally initialized by windows...quote:Just suspend the rendering context thread until the other one is done?My comment implies that the window creation thread RESUMES the rendering context thread when it''s done and ready. Next time I shall endeavor to spell everything out in little details, perhaps even with MSDN links that show you exactly how to do it because no one actually reads stuff on these forums anyway.Or just don''t even make the RC thread until it''s ready (thats what you should do if you persist in this design). ;  This specific method is given as tip number 1.12 (Page 80) in Game Gems 2.The busy wait is fine to get things working, but is not generally a good thing (I guess that is what the previous statement of ''This is by no means the best way to do things'' means).Read up on semaphores (semaphores mixed with a simple messaging api can make the decision to use multiple threads completely transparent).;  ok, problem fixed...thanks for the replies guys A little explanation (cause im dumb):The 1st thing my Thread (A) that creates and handles the windows does is create a window resource handleUINT hPW = Core.RWnd->New(); // Primary Window (pw) HandleAnd then it feeds it to the global capabilities class:Core.Caps.Set("Rend_PW_Handle", hPW);Later, after creating the window, it sets the primary window''s HWND into the Caps too:Core.Caps.Set("Rend_PW_HWND", (int)hWnd);Meantime, my (B) thread was waiting for "Rend_PW_Handle" to get set, which was set immediatly upon entering the (A) thread.Now (B) waits for "Rend_PW_HWND" to be set, which only happens after window creation, and doesnt fail like before... [Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD]    [Yann  L.][Enginuity]  [Penny Arcade]  [MSDN][VS  RoadMap][Humus][BSPs][UGP][NeHe]"I say we take off and nuke the entire site from orbit. It''s the only way to be sure." ;  No prob, I appreciate it when advice is ignored. 