Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Making the workspace / project loading asynchronous?

(1/2) > >>

rickg22:
Yiannis, I was looking at the code and I have this proposal for post-1.0...

What needs to be done so we can make the workspace / project loading asynchronous?

i.e. instead of returning a value of success / failure, make it trigger some events like OnWorkspaceLoaded and OnWorkspaceFailedLoading ?

I say this because workspace / project loading is one of the slowest routines of C::B, and this was one of the reasons for wanting to insert wxYield's in there.

So the current model is more or less like this:

(Synchronous)
Load Workspace -> Lots a stuff with lots of wxYield's in the middle -> Return value

I want to change it to:

(Asynchronous)
Load Workspace -> Idle Event handling for workspace / prj loading -> Success / Failure events

In other words, I want to make explicit the "interruptions" (event handling) that happen in the middle of workspace / project loading, and give more order to it. This would get us rid of the wxYield's and their consequences like having to insert SANITY_CHECK's all over the place in the workspace loading areas.

The part that looks difficult is that I'd have to modify the *workspaceloaders... any ideas?

mandrav:
I don't agree. It's overcomplicating things, not to mention that it is asking for trouble...
What problems do you have when loading workspaces?

rickg22:
I just want to get rid of the wxYield's. If you disable them ("improved stability" under "environment options", "tweaks"), the interface becomes unresponsive while loading the project. But keeping the wxYields in the message manager is asking for trouble, see http://forums.codeblocks.org/index.php/topic,726.0.html and http://www.wxwidgets.org/manuals/2.4.2/wx30.htm#wxappyield. My point is that if we keep having those wxYields, we'll have to deal with unexpected crashes on EVERY version.

So, how about an intermediate solution, like asynchronous loading of the layout for projects?

mandrav:
Can you define "asynchronous"?
If you 're thinking of threads, you can forget it ;) The sdk is *not* thread-safe...

I believe a progress dialog should be enough clue for the user of what's going on and you can remove the wxYields too. Every other solution is just too much, at least for now. Just my 2c.

rickg22:

--- Quote from: mandrav on September 05, 2005, 09:37:16 pm ---Can you define "asynchronous"?

--- End quote ---

Asynchronous: Not synchronous. i.e. it would run in the background. My plan was not to use threads, but background processing with events.

I tested this idea in my PC when you were gone, this is why I added the OnIdleEvent handler for projectmanager.cpp. What I did for my test was popping up a messagebox every N idle cycles. It appeared every  3 or 4 seconds. So "yep", that could work :) The idle handler would check if a project's layout was being loaded, and open the files one by one.

My reason for using the Idle event was because using command events would freeze the GUI. The Idle events are only handled after the window messages are processed. I thought about it for a lot time, and it seems (to me at least) an elegant solution to the "GUI freezing" problem.

My original idea was to do the project loading in the idle handler, but i hadn't realized that this would have to chain to the workspace loading.

However, I think that the Layout loading (opening of files) can be done this way. We know what operations to perform, and the timing isn't critical. (Maybe the project tree generating could be done this way, but that would require further analysis. I'd rather focus on the layout loading for now).

So, what do you think?

Navigation

[0] Message Index

[#] Next page