Force Newton to one thread?

[tshannon]

This is probably a strange request, but I've run into a bit of a wall with my Go bindings for Newton. Basically Go (in its current runtime) doesn't support being called from a thread it didn't created. In order to do the newton callbacks in Go, I need to call Go from the C side of things. Since newton is running multi-threaded, Go's runtime isn't aware of the calling thread from any of the callbacks.

Is there any way to force newton to run single threaded, or force the callbacks to be made on the originating thread? If not, I may have to abandon these bindings until the runtime supports multiple threads.

[Julio Jerez]

In the comand line to compile the eneigne you can define DG_USE_THREAD_EMULATION
and it will build the engine without threads sopport.

[tshannon]

Wow, that looks to fit the bill perfectly. I'm also looking at options for polling for the callback thread passing the function pointer back to the main thread. That might take to long though.

As for DG_USE_THREAD_EMULATION, I can't get it to compile with that preprocessor, either with my previously buildable SVN copy, or the latest SVN. I'm getting the same error with both:

Code: Select all

../../source/core/dgThread.cpp: In constructor ‘dgThread::dgSemaphore::dgSemaphore()’:
../../source/core/dgThread.cpp:63:10: error: no match for ‘operator=’ in ‘((dgThread::dgSemaphore*)this)->dgThread::dgSemaphore::m_sem = 0l’
../../source/core/dgThread.cpp:63:10: note: candidate is:
In file included from /usr/include/semaphore.h:30:0,
                 from ../../source/core/dgTypes.h:93,
                 from ../../source/core/dgStdafx.h:25,
                 from ../../source/core/dgThread.cpp:22:
/usr/include/x86_64-linux-gnu/bits/semaphore.h:41:3: note: sem_t& sem_t::operator=(const sem_t&)
/usr/include/x86_64-linux-gnu/bits/semaphore.h:41:3: note:   no known conversion for argument 1 from ‘long int’ to ‘const sem_t&’


I'm on Ubuntu 12.10 64bit.

[Julio Jerez]

Oh the mutex selction was not compile out, I added and better the codional compilation mode. please sync an dtry again.

Wow, that looks to fit the bill perfectly. I'm also looking at options for polling for the callback thread passing the function pointer back to the main thread. That might take to long though.

I do not understand this question can you rephrase it?

[tshannon]

Same error.

Code: Select all

../../source/core/dgThread.cpp: In constructor ‘dgThread::dgSemaphore::dgSemaphore()’:
../../source/core/dgThread.cpp:63:10: error: no match for ‘operator=’ in ‘((dgThread::dgSemaphore*)this)->dgThread::dgSemaphore::m_sem = 0l’
../../source/core/dgThread.cpp:63:10: note: candidate is:
In file included from /usr/include/semaphore.h:30:0,
                 from ../../source/core/dgTypes.h:93,
                 from ../../source/core/dgStdafx.h:25,
                 from ../../source/core/dgThread.cpp:22:
/usr/include/x86_64-linux-gnu/bits/semaphore.h:41:3: note: sem_t& sem_t::operator=(const sem_t&)
/usr/include/x86_64-linux-gnu/bits/semaphore.h:41:3: note:   no known conversion for argument 1 from ‘long int’ to ‘const sem_t&’
make: *** [../../source/core/dgThread.o] Error 1


And I was just talking about changes I could try on my end to capture the thread and bring it back to a thread that Go is aware of.

[tshannon]

Sorry, I think this has nothing to do with the DG_USE_THREAD_EMULATION option, as I'm getting the same error compiling the latest without it. I'll try and apply your latest changes to my known working copy and see if I can get it to compile with the DG_USE_THREAD_EMULATION option.

[Julio Jerez]

all you need to do is set DG_USE_THREAD_EMULATION in the make file, like this

FLAGS = -c -Wall -Wno-strict-aliasing -D_POSIX_VER -DDG_USE_THREAD_EMULATION $(CPU_FLAGS) -I$(DG_INCLUDED_PATH) -I$(DG_INCLUDED_PHYSICS_PATH) -I$(DG_INCLUDED_MESH_PATH) -I$(DG_INCLUDED_OPENCL_PATH) -I$(DG_AI_PATH)

[tshannon]

Yep, that's exactly what I did, and I'm saying I'm getting I'm getting that error whether I set -DDG_USE_THREAD_EMULATION or not.

[Julio Jerez]

Oh sorry ther was another pthread type, that has to be if def out.
It is fixed now, please try again.

[tshannon]

Excellent. All is working great now, and it perfectly resolves my threading issue with the Go interface.