Threading in DarkRadiant

[OrbWeaver]

I appear to have successfully implemented the use of threads when displaying the Entity Class Chooser, so that the dialog appears immediately without having to wait for the entity classes to be loaded. This is better practice from a UI point of view (always provide immediate feedback), and could be used in several other places where lengthy operations are performed.

 

greebo, are you happy for me to commit these changes? The reason I ask is that threading is the sort of issue that can be both platform-dependent and tricky to debug, so I don't want to dump a whole load of Windows breakage on you if you are not prepared for it.

[greebo]

If you're using boost::threads then by all means go for it. We can also do it in a separate branch and I'll check it out there, if you want.

[OrbWeaver]

If you're using boost::threads then by all means go for it.

 

Glib::Thread actually, which is the same basic principle (platform-independent thread functionality), but using the sigc++ signals and slots rather than boost::functions.

 

I'll commit to the trunk for now then, and the change can always be backed out or put behind #ifdefs if there is a problem — in fact disabling threads would be a one-line change: replacing Glib::Thread::create(...someFunction...) with a direct call to someFunction() itself.

[greebo]

I'm getting an "An unspecified error has occurred" message when launching the Entity Chooser (and DarkRadiant is aborted thereafter), I'll have to check what the heck that means.

[OrbWeaver]

I'm getting an "An unspecified error has occurred" message when launching the Entity Chooser (and DarkRadiant is aborted thereafter), I'll have to check what the heck that means.

 

Well, that sucks. Could there be some configuration option required to build Glibmm with thread support? I think Boost has something like that.

[greebo]

I figured it out, luckily I found it quickly after compiling the gtkmm stack from scratch, which gave me the symbols and the call stack. The reason behind the crash was a missing call to g_thread_init(), which I added to main.cpp, and now it's working.

 

It's a nice addition to the EntityClass Chooser, the only thing I noticed is the missing border in the window, it used t have the standard 12px padding.

[OrbWeaver]

I figured it out, luckily I found it quickly after compiling the gtkmm stack from scratch, which gave me the symbols and the call stack. The reason behind the crash was a missing call to g_thread_init(), which I added to main.cpp, and now it's working.

 

Oh yeah, I should have guessed there would be something like that to initialise the thread support. Although it seems that it will not be necessary according to the documentation for the unstable Glibmm build; perhaps it will be done automatically when everything else is initialised.

 

It's a nice addition to the EntityClass Chooser, the only thing I noticed is the missing border in the window, it used t have the standard 12px padding.

 

Oops, I forgot about that when I switched the HBox to a HPaned. It is now restored.