A place to discuss everything related to Newton Dynamics.
Moderators: Sascha Willems, walaber
by tshannon » Mon Jan 28, 2013 10:45 pm
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.
-
tshannon
-
- Posts: 22
- Joined: Wed Sep 05, 2012 3:21 pm
by Julio Jerez » Tue Jan 29, 2013 7:15 am
In the comand line to compile the eneigne you can define DG_USE_THREAD_EMULATION
and it will build the engine without threads sopport.
-
Julio Jerez
- Moderator

-
- Posts: 12426
- Joined: Sun Sep 14, 2003 2:18 pm
- Location: Los Angeles
-
by tshannon » Tue Jan 29, 2013 9:52 pm
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.
-
tshannon
-
- Posts: 22
- Joined: Wed Sep 05, 2012 3:21 pm
by Julio Jerez » Wed Jan 30, 2013 10:58 am
Oh the mutex selction was not compile out, I added and better the codional compilation mode. please sync an dtry again.
tshannon wrote: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?
-
Julio Jerez
- Moderator

-
- Posts: 12426
- Joined: Sun Sep 14, 2003 2:18 pm
- Location: Los Angeles
-
by tshannon » Wed Jan 30, 2013 12:04 pm
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
-
- Posts: 22
- Joined: Wed Sep 05, 2012 3:21 pm
by tshannon » Wed Jan 30, 2013 12:46 pm
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.
-
tshannon
-
- Posts: 22
- Joined: Wed Sep 05, 2012 3:21 pm
by Julio Jerez » Wed Jan 30, 2013 1:02 pm
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)
-
Julio Jerez
- Moderator

-
- Posts: 12426
- Joined: Sun Sep 14, 2003 2:18 pm
- Location: Los Angeles
-
by tshannon » Wed Jan 30, 2013 1:12 pm
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.
-
tshannon
-
- Posts: 22
- Joined: Wed Sep 05, 2012 3:21 pm
by Julio Jerez » Wed Jan 30, 2013 3:20 pm
Oh sorry ther was another pthread type, that has to be if def out.
It is fixed now, please try again.
-
Julio Jerez
- Moderator

-
- Posts: 12426
- Joined: Sun Sep 14, 2003 2:18 pm
- Location: Los Angeles
-
by tshannon » Wed Jan 30, 2013 3:56 pm
Excellent. All is working great now, and it perfectly resolves my threading issue with the Go interface.
-
tshannon
-
- Posts: 22
- Joined: Wed Sep 05, 2012 3:21 pm
Return to General Discussion
Who is online
Users browsing this forum: No registered users and 1 guest