On Mon, 04 Apr 2011 13:08:51 +0200, Jan Kundrát wrote:
First of all, I wonder what your reason is to go with boost's threading over Qt's facilities, given that your application is already tightly bound into using Qt (you're using their event loop and events).
Well, disclaimer on that - Wasn't my idea. My task is to get it to work. But basically, there's the GUI section of code, and the work section of code and the two have very little to do with each other, as there's 3 different GUI tool kits that are used depending on the project. The "configurator" (which runs in the background) calls the toolkit with a list of windows that need to be created.
Are you sure that the Qt's event loop is running? Are both threads executing their own event loop? (You should check this one, it depends on you if you want each thread to run an event loop, or do something else. In any case, make sure you understand the semantics of QCoreApplication::postEvent and how these events are delivered).
Hmmm. That's definitely something I need to look into. It seems to be deadlocking on the mutex's, but it might be stopping there. The code reportedly works fine in Linux, Mac, and XP, but chokes on Win 7. (I'm the short-straw dev who's forced to use 7.) I'll read up here next.
Finally, you code is missing some context to understand what you're trying to achieve. I have no idea what the "qtService" stands for, not what "s" is, if there are any classes derived from the QObject, how you intend to use the events, etc etc.
From what I understand, the basic gist is that a piece of code, like the GUI creation, MUST run from the main thread, and this code takes care of that, switching the context to the main thread (Or whatever thread is requested). As for what qtService means, I haven't the foggiest. It's definitely NOT descriptive enough for my tastes, as it seems to be one step away from qtGoDoSomething.
Cheers, Jan
Thanks for the feedback! =) Time to hit the manuals again. (Probably both figuratively and literally)