solving wxYield problem once and for all: Finding a viable alternative.

[rickg22]

I made a few tests with the MessageManager and wxApp's various processing functions. I think I found the way to solve the reentrancy problem.

My current test was compiling a file (or the whole C::B project) while scrolling up and down with the cursor in a large source file (using the up and dn arrow keys). This way i could notice if there was a significant delay while doing a certain task, or if the pressing of the keys delayed the message windows.

Current code:

Code

wxTheApp->Yield();

This is the current code, and obviously has reentrancy problems, BAD!

My first approach was this:

Code

while(wxTheApp->Pending())
   wxTheApp->Dispatch();

Because I saw it on the wxWidgets manual.

Results: Compiling a single file apparently took about a minute instead of the 4 seconds. The reason: The messages for "linking" weren't processed until i stopped doing all activity. So this was bad, too!

Then I tried this solution:

Code

wxTheApp->ProcessPendingEvents();

And it worked! Compiling a file (no matter how much i kept scrolling down the sourcefile) displayed the "4 seconds" message on time, instead of waiting for the DLL linking.

I noticed an occasional 1/10th of a second delay when some of the messages were displayed, but that's a good thing, it means the system is working without reentrancy.

What processPendingEvents does, is getting the list of pending events (wxPendingEvents is the global list of event handlers with pending events) and processing them. However, it does NOT process new Window messages from the Windowing System (X, GTK, Windows). These will ONLY get processed after returning from the current procedure.

In other words, new events created with the mouse, menus, or keyboard, do NOT enter the message loop, until ProcessPendingEvents is finished. And that's what we're looking for: Zero reentrancy!

EDIT: I haven't tried the following code, but it MIGHT JUST WORK.

Code

Manager::GetMessageManager()->DebugLog(orwhatever)->ProcessPendingEvents()

This could go in the MessageManager code so the Log would process its pending events without having to wait for the other event handlers to process their events - they'll have their chance.

Yiannis, your stance?

[killerbot]

In other words, new events created with the mouse, menus, or keyboard, do NOT enter the message loop, until ProcessPendingEvents is finished. And that's what we're looking for: Zero reentrancy! Very Happy

Does that mean that while I am compiling , I can not type in new code in a source file??

[rickg22]

No, because compilation is done with interprocess communication. You cannot type only while the latest message is being displayed. See wxProcess for details.

EDIT: I already replaced Manager::Yield with a new function called Manager::ProcessPendingEvents(). (It does
the same checks than Yield, but calls wxTheApp->ProcessPendingEvents() instead) in all the message manager
methods.

Then I recompiled the whole SDK while typing "asdfkjhlasdflhj" all over :mrgreen:. The ONLY delay i experienced
was when I got the message "Process terminated with status 0"

I'm going to test other places and see if there's any significant unresponsiveness.

EDIT: I found some very annoying delay when compiling, at the part that calculates the commands for the targets. I put a Manager::Yield in strategic loops inside DirectCommands, and the unresponsiveness is 90% gone.

[rickg22]

After testing exhaustively, i decided that this change was stable enough. Committed at revision 1756