Multithreading

[Sweenie]

Hi.

I've been trying to find out why after a while of using Newton inside Unity 3D, Unity sometime freezes when closing the application.

At first I thought it might be because I forgot to delete a body or something and therefore caused a leak.

But then I found a forum thread that mentioned that Unity waits for all created threads upon exiting, even threads not created by Unity.

When does Newton create new threads?
I assume new threads are created when I call NewtonUpdate() but these threads should be closed as soon as NewtonUpdate() returns right?

Is there anywhere else Newton can create a Thread that keeps running?
After I call NewtonDestroy() there shouldn't be any thread still running right?

I know about NewtonWaitForUpdateToFinish() but isn't that only relevant if using NewtonUpdateAsync() ?

[EDIT]
This is a quote from a Unity staff

When the application exits - UnityEditor or WindowsStandalone player, mono scans all the threads in the application and tries to close them, it also catches threads created by you, even if they were created from C++ not from C#, because mono didn't expect this, at some point it goes into infinite loop.

Mono uses OpenThread (THREAD_ALL_ACCESS, TRUE, threadID) to access the designated thread. So to workaround this problem, you have to create a thread using DELETE restriction by passing special SECURITY_ATTRIBUTES, this way mono will ignore this thread.

[Julio Jerez]

if Unity required that all thread to be destroyed on exist, them
NewtonWaitForUpdateToFinish is not enough, you then need to destroy the world.
before exiting because the newton at a minimum is two threads.
On thread Is the one the runs the engine, and block the caller thread until the engine finish the update. in the mode the caller is blocked

when running asynchronous, the asynchronous thread wraps the engine thread. when the update is called, the application signal the asyn thread to run an update, and wait for the update to finish.
the teh Asynthread signal the running thread to run the update and that thread get block, however the parent has returned to the application. so nether the engine and the app runs concurrently. bo the asyn thread is blocked waiting for engine thread to finish.

If the app call for another update the that update is block until the engine finish update that is already running.
NewtonWaitForUpdateToFinish is joust a call wait for single object and the objet is the semaphore that the engine thread signal when complete the frame.

you will have to call
NewtonWaitForUpdateToFinish and the destroy the world, so that all threads are terminated before Unity force the thread to shot down.

no doing it the world will be alive and at some point the destroy will try to close the tread again by it will have invalid thread handles.

we show probably add code that handle the case when a thread is shut down by the OS, and then the engine the try to close those thread in destructions.
I will try to add that tomorrow,
but yes I can see how that could be a bad crash.

on the other hand I find weird, even wrong that Unity meddle with resource it did do not created.
This is like an application taking a memory pointer in a class, deleting it and leaving the class with a dangling number. But that's how it is.

[Sweenie]

Well, I always destroy the world before exit.
I just wanted to make sure that there couldn't be any lingering thread by any chance.

The only way to prevent a proper shutdown in Unity is to debug and stop or simply kill the unity process in taskmanager.

Anyway, I just discovered the awesome tool called Process Hacker.
Running that tool, rightclicking Unity.exe in the processlist -> choose Properties -> and finally click on the "Threads" tab I could see all threads running and better yet, I could see which threads Newton was creating.
I've set Newton thread count to 4 and I could see those 4 threads are running. But I also see a 5:th thread starting but doing nothing at all, using no cpu.

And when I press Stop in the Unity Editor, those 5 threads close down nice and clean.

I've started and stopped Unity Editor for over 40 minutes trying to trigger the Editor to freeze but now it wouldn't freeze.

It happens rarely and I'm not sure what causes it. In fact, i'm starting to believe it has nothing to do with Newton at all.

Will try again tomorrow. I need to reproduce this somehow.

Don't bother with adding any code yet. I'm sure Newton is doing everything right.

[Sweenie]

Ha, got two freezes today and both times Unity was waiting for a thread it created itself, some thread handling flushing of the audio buffer. I haven't even touched the audio stuff in Unity yet so this must be a Unity bug.

Hmm, it seems it wasn't freezing though, after about 30 seconds while I was peeking at all running threads suddenly Unity shut down. I guess it was some cleanup procedure that took an unusual long time to finish.