more research on windows problems

This commit is contained in:
David Rose 2009-07-15 18:36:38 +00:00
parent 6404f074b9
commit a088d7ff72
4 changed files with 24 additions and 55 deletions

View File

@ -643,35 +643,6 @@ request_stop() {
}
}
////////////////////////////////////////////////////////////////////
// Function: P3DInstance::pump_messages
// Access: Public
// Description: Windows only: pump the message queue on this
// instance's parent window, so that any child-window
// operations will be able to continue.
////////////////////////////////////////////////////////////////////
void P3DInstance::
pump_messages() {
#ifdef _WIN32
if (_got_wparams) {
HWND hwnd = _wparams.get_parent_window()._hwnd;
if (hwnd != NULL) {
MSG msg;
nout << " peeking " << hwnd << "\n" << flush;
// It appears to be bad to pump messages for any other
// window--Mozilla is apparently not reentrant in this way.
if (PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE | PM_NOYIELD)) {
nout << " pumping " << msg.message << "\n" << flush;
TranslateMessage(&msg);
DispatchMessage(&msg);
nout << " done pumping\n" << flush;
}
}
}
#endif // _WIN32
}
////////////////////////////////////////////////////////////////////
// Function: P3DInstance::make_xml
// Access: Public

View File

@ -82,7 +82,6 @@ public:
void start_download(P3DDownload *download);
inline bool is_started() const;
void request_stop();
void pump_messages();
TiXmlElement *make_xml();

View File

@ -669,14 +669,6 @@ wait_script_response(int response_id) {
// here; the full message pump seems to cause problems.
MSG msg;
PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE | PM_NOYIELD);
/*
if (PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE | PM_NOYIELD)) {
nout << " pumping " << msg.message << "\n" << flush;
TranslateMessage(&msg);
DispatchMessage(&msg);
nout << " done pumping\n" << flush;
}
*/
#endif // _WIN32
nout << "." << flush;

View File

@ -346,7 +346,6 @@ command_and_response(TiXmlDocument *command) {
for (ii = _instances.begin(); ii != _instances.end(); ++ii) {
P3DInstance *inst = (*ii).second;
inst->bake_requests();
inst->pump_messages();
}
_response_ready.acquire();
@ -359,27 +358,35 @@ command_and_response(TiXmlDocument *command) {
#ifdef _WIN32
// Make sure we process the Windows event loop while we're
// waiting, or everything that depends on Windows messages--in
// particular, the CreateWindow() call within the subprocess--will
// starve, and we could end up with deadlock.
// waiting, or everything that depends on Windows messages within
// the subprocess will starve, and we could end up with deadlock.
// A single call to PeekMessage() appears to be sufficient. This
// will scan the message queue and deliver messages to the
// appropriate threads, so that our subprocess can find them. If
// we don't do this, the messages that come into this parent
// window will never get delivered to the subprocess, even though
// somehow the subprocess will know they're coming and will block
// waiting for them.
MSG msg;
PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE | PM_NOYIELD);
/*
MSG msg;
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE | PM_NOYIELD)) {
// nout << " pumping " << msg.message << "\n" << flush;
TranslateMessage(&msg);
DispatchMessage(&msg);
// nout << " done pumping\n" << flush;
}
*/
#endif // _WIN32
// We wait with a timeout, so we can go back and spin the event
// loop some more.
_response_ready.wait(0.1);
// loop some more. On Windows, the timeout needs to be small, so
// we continue to process windows messages in a timely fashion.
_response_ready.wait(0.01);
#else
// On other platforms, we shouldn't need a timeout at all--we
// could just block indefinitely--but we go ahead and put one in
// anyway, just in case a notification slips past somehow, and
// also so we can see evidence that we're actively waiting. This
// timeout doesn't need to be nearly so small, since it's only a
// "just in case" sort of thing.
_response_ready.wait(0.5);
#endif // _WIN32
nout << "." << flush;
ri = _responses.find(response_id);