This is mainly for KungFooMasta and Stardragon, but anyone else is welcome to get involved. The discussion we were having about different message passing systems really got me thinking, and after a lot of sketching, brain-twisting, coding and debugging I finally have something to show for it. I'm calling it AppCore (short for Application Core Abstraction Layer). I put up a small wiki page
describing the various components and use, and it comes with a script to generate Doxygen files. Anyway, if youguys want to check it out and maybe play around with it a little, I'd appreciate the feedback and inevitable bug discovery!
I tried to keep it as simple as possible; it's only around 2500 lines of code (3000 with samples) and builds in under 5 seconds (still less than 10 with samples), and comes with a really lightweight CMake build system. The only dependency is pthreads, but it's built with the intent of future support for virtually any threading library instead. It's hosted in our Bazaar repository, which you can checkout like this:
bzr checkout --lightweight lp:judgmentday
I think the ActiveMember class is the most confusing to me. Is it possible you can post one of the examples on the wiki, or on this forum?
Sure, here's a zip file the current revision.
The and ActiveMember will usually be the master of a particular subsystem. You can then call, for example,
mGameLogic = new GameLogic();
mGraphicsSystem = new GraphicsSystem();
mNetworkSystem = new NetworkSystem();
to run everything. This code would create three threads, call the run() method of each object, and then wait for all of them to exit. The run() methods will typically contain some loop like this:
void run ()
... // Do stuff
where mContinue can be set to false when the object receives a certain message, say "QuitSignal".
Ah, that makes sense. Maybe you should just rename "ActiveMember" with "Thread".
No, it doesn't itself represent a thread, it's just used as a root of execution for a thread. There actually is Thread class though, that acts as a platform independent interface to a few common thread operations. Thread's must always be initialized with a ThreadExecutable object, which is basically an abstract representation of "anything you can call". At the most basic level, ActiveMember's are just glorified ThreadExecutables that are more tightly linked with the CPU in a number of ways.
I've only just got back to this after a long absence due largely to a major relocation and a new job. I can't believe that you've gone ahead with this, based as it was on one of my silly ideas, and I'm really looking forward to having a look through the code...
What can I say.
Welcome back SD! Hope the last few months haven't been too
traumatic for you!
I've made some huge changes to AppCore since this post (see the Object Oriented Threading
post), but if you want to see the "final-ish" version of that design, check out revision 59
of our Bazaar repository. My final verdict on this was that it's an extremely nice system that simply has too much overhead (at least the way I wrote it) for anything that needs writing in C++. The long OOT post reflected my shifting priorities to a simplified and more efficient system of dealing with multithreaded complexity, and that one has really held up over the past few months. While it's not quite as sugar-coated as your original idea, there's virtually no overhead to speak of. AppCore has since evolved into a nice little collection of handy classes for messaging and serialization as well as the threading system at its foundation. I've also given it its own Launchpad project and repository and started putting together some documentation here
Thanks for the welcome back, Calder!
Things haven't been too traumatic, just... well, hectic. And difficult. It's also been pretty fun: right now I'm working on a major area of code which also needs to run multithreaded... and when I saw my final design I couldn't help but think of AppCore *laughs and facepalms*
I'm a great fan of keeping things simple, and to be honest the whole idea was, as I think I said elsewhere, one of those "what if...?" ideas that one tends to have. I look forward to looking through the docs and the code
... do I get a mention anywhere? *laughs at himself*
I honestly don't know if I'll do anything with this idea... I have so little free time these days.
Maybe write an article in Game Programming Gems or something, and link it to AppCore
Still... in all seriousness I'm really honoured that you took my idea and ran so far with it. Thank you.
Most certainly! Added a "Developers" section just for you!
(refresh the homepage
) I put you as "design inspiration for messaging system" (the most loquacious of the three credits). If you can think of anything more appropriate, pray tell! Also, if you're interested in potentially expanding the messaging system, I would be open to that. I've gotten around to adding return functionality to the threading system, but not to the messaging system yet. The trouble is doing it with as little excess complexity and inefficiency as possible, because the last thing I want is to fall right back into the realm of "unusably slow".
Colour me most certainly interested!
Unfortunately right now I'm in the throes of crunch at my workplace, so everything from Return of the Sentinel
to my music to my novel to --- oh, you get the idea.
What's also interesting is that I've been working on multithreading a fair bit, and one of the ideas I had for the project sort-of falls into this sort of area. At one point, when I realised I was getting a bit too professor-ish and pulled myself up sharply, the system was starting to turn into something of a mini-OS of its own...
Thank you for the credit, by the way
'Tis very kind of you
I'll take a look at the code this weekend and then split off (yet another) background process to think about it...
I look forward to your feedback as always!
Be sure to read the Object Oriented Threading thread first; the design of the threading module should make a lot more sense after that.