Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Oct 2013
Offline Last Active Today, 04:10 PM

Posts I've Made

In Topic: cmake linking errors

19 October 2014 - 01:43 PM

CMake actually thought the "6_6" part in "x86_64" was some kind of version number and replaced it by 2.7. Epic fail.

Might that have something to do with the way I'm forcing boost to use python 2.7?
        # hack to force boost to use python2.7
        string (REGEX REPLACE "[0-9].[0-9]" "2.7" Boost_PYTHON_LIBRARY ${Boost_PYTHON_LIBRARY})
(See here for related thread)

Anyway, have you tried linking boost_python before python? It is my understanding that the normal linker order is left-to-right, i.e. dependencies come last, unless you are using a nonstandard linker like on Windows or some special option such as the "scan twice" option of GNU ld to resolve circular dependencies.

It's very strange because the project I linked in the OP compiles fine on my desktop computer. My laptop can't compile it for some reason. wtf. Re-arranging the linking order doesn't do anything, which makes sense because linking order is only relevant when linking against static libraries.

Both are Gentoo, both are amd64... The only difference is that on my laptop boost_python isn't installed so CMake will download that dependency.

In Topic: Funniest line of code ever ?

07 October 2014 - 09:55 AM

Somewhere in a text editor application I saw this line:

const char* CARROT = "^";

In Topic: Post your desktop (2014)

07 October 2014 - 04:27 AM



Linux 3.14.14-gentoo Intel® Core™ i5-2410M CPU @ 2.30GHz GenuineIntel GNU/Linux

Xorg/KDE4 with custom dark theme

In Topic: Multithreading issues: Unit test fails sometimes

02 October 2014 - 01:09 PM

Apparently poll returns "The number of handlers that were executed" - you should probably assert that the return value is 1000 as part of your test.

I just tested this and the value returned by poll() is never 1000. Not even close to 1000, it's hovering somewhere around 100-300.
Is there a way to suspend the main thread until all 1000 entities have been processed? This is the core of my problem and would solve everything.

    for(entity : m_EntityList)
                boost::bind(&System::processEntity, this, boost::ref(entity))
    // this here is not doing what I thought it did. How can I wait until all entities are processed here?

There are no synchronization points, no locks around containers and/or use of lockless thread safe containers, there are functions that are not reentrant safe, and so on.

The design I'm aiming for should fundamentally not require any of that. The only time I will need to synchronize objects is in the event of entities accessing other entities. What I'm trying to do is something like this:
System1 update
    --> process all of System1's entities asynchronously
    --> wait for processing to finish
System2 update
    --> process all of System2's entities asynchronously
    --> wait for processing to finish

In Topic: Threading question

02 October 2014 - 05:43 AM

Would making the member variables of the components atomic also be an option?